ASL Tickets — Source library
Public documentation snapshot: 2026-10-17
Help desk ticketing software: track support requests inside your application
ASL Tickets helps teams record, assign and follow up on support requests within their applications. Review ownership, access and integration workflows.
Help desk ticketing software: track support requests inside your application
Stop losing track of who asked for what.
Help desk ticketing software: track support requests inside your application
Every request your team gets, tracked and owned, inside the product they already use.
Help desk ticketing software: track support requests inside your application
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.
ASL Tickets exists because of this.
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.
ASL Tickets exists because of this.
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.
ASL Tickets exists because of this.
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.
ASL Tickets exists because of this.
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.
How ASL Tickets works, start to finish.
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.
How ASL Tickets works, start to finish.
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.
How ASL Tickets works, start to finish.
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.
How ASL Tickets works, start to finish.
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.
How ASL Tickets works, start to finish.
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.
How ASL Tickets works, start to finish.
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.
How ASL Tickets works, start to finish.
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.
How ASL Tickets works, start to finish.
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.
How ASL Tickets works, start to finish.
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.
How ASL Tickets works, start to finish.
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.
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 native Android client reached version 1.0.0: connect, create a request, assign it, change status and priority, reply, resolve it, see the same state on a second device, recover from a lost network, relaunch with the session intact, and clear the session. 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?
Tickets is included with the products that carry it. 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.
How safe is the content people put in a request?
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.
Is it actually ready, or are we going to be the ones finding the problems?
The Android app does not have search, escalation rules or an export screen yet, 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.
Who at Auto Secure Login can read our requests?
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
Simple help desk ticketing software inside the product your team already uses
ASL Tickets is for an office manager, practice owner, utility administrator or small business team that has been tracking requests in a shared mailbox. It is help desk ticketing software carried inside Auto Secure Login products: each request gets a number, one of five states, one of four priorities and a named owner, and the person who filed it can watch it move.
Simple help desk ticketing software inside the product your team already uses
Ticket management follows simple access controls. Requesters can open a request and reply, only agents and organization admins can change its status, priority or assignment, and each change is recorded with the name of the person who made it. Someone from another organization who asks for one of your requests is told it does not exist.
Simple help desk ticketing software inside the product your team already uses
It is deliberately small. There are no response-time or service-level timers, escalation rules, automatic routing or search yet, and every request is visible to all colleagues with access to the panel, so it is no place for clinical detail, passwords or payment data.
Help desk ticketing software: a practical buyer's guide
Help desk ticketing software turns each request into a record with an owner and a status. Without it, requests scatter across inboxes, texts and hallway talk, and nobody can say what got done. This guide covers what help desk ticketing systems do, what to compare, and where ASL Tickets fits.
What a ticketing system does
Large or small, every ticketing tool does a few core jobs:
What a ticketing system does
Capture. A request becomes a numbered ticket, whatever channel it came from.
What a ticketing system does
Ownership. Each ticket has one person responsible, so nothing sits unclaimed.
What a ticketing system does
Status and priority. Anyone can see whether a ticket is new, in progress, waiting or done, and how urgent it is.
What a ticketing system does
History. Replies and changes stay attached, so the reasoning survives a staff change.
What a ticketing system does
Live chat and tickets do different jobs. Chat answers a quick question in real time. A ticket holds work that takes longer or passes between people.
What to compare
Start with a list of what your team actually needs. Then check each tool against it:
What to compare
Channels. Note where requests arrive today: emails, chats, phone calls, web forms or a panel inside your own app. Check which ones a tool turns into tickets and which still need retyping.
What to compare
Self-service. A knowledge base lets people answer common questions on their own. It pays off when the same questions keep coming back.
What to compare
Automation. Larger tools route tickets by rules, run service-level timers and escalate overdue work. A small team may not need this at first.
What to compare
Reporting. Look for ticket volume over time, time to first reply and time to resolution. Some tools also send customer satisfaction surveys when a ticket closes.
What to compare
Search and organization. Tags, categories, custom fields and search matter more as the queue grows.
What to compare
IT features. Internal IT teams often want asset management, so a ticket about a laptop links to that laptop's record.
What to compare
Access and privacy. Ask who can read each ticket, what notification emails contain and where the data is stored.
What to compare
Data in and out. Check import from your old system, export when you leave and how long records are kept.
What to compare
Fit. Ask what customization support is included and what costs extra.
Hosted, self-hosted, open source and pricing
Many help desk tools are hosted: the vendor runs the software and you sign in through a browser. Self-hosted tools run on your own servers. That gives you more control, but updates, backups and security become your job. Open source options usually carry no license fee to self-host, though your staff time still costs money.
Hosted, self-hosted, open source and pricing
Zoho Desk, Jira Service Management and HubSpot Service Hub are well-known examples of the category. Judge any tool against your own list rather than the length of its feature page.
Hosted, self-hosted, open source and pricing
Pricing models vary. Common ones are a monthly fee per agent, tiered plans that unlock more features, and a free plan with limits. Ask how the price changes as your team grows, and whether features you need sit in a higher tier.
Where ASL Tickets fits
ASL Tickets is a small ticketing service carried inside Auto Secure Login products. It sits behind the sign-in your team already uses and has no separate sign-in page of its own. Signed-in users file requests from the panel inside the product. People with no account can use the public support page, and their message becomes a tracked request in the same queue. Staff away from a desk can use a signed Android app, available directly from us.
Where ASL Tickets fits
Each request gets a number, a status, a priority and a named owner. Subjects, request text and replies are encrypted where they are stored, though the service holds the key. Notification emails name the request by its subject but never carry the request text or replies. Everyone in your organization who can open the panel sees all of its requests.
Where ASL Tickets fits
Measured against the checklist above, it is deliberately small:
Where ASL Tickets fits
Replying to a notification email does not add a comment.
Where ASL Tickets fits
There are no service-level timers, escalation rules, scheduled reminders or automatic routing.
Where ASL Tickets fits
There is no search, filtering, tags, categories or custom fields. A view shows the 100 most recently updated requests, so it suits a modest ticket volume.
Where ASL Tickets fits
There is no bulk import, no self-service export and no delete. If you leave, ask and we hand your request history back.
Where ASL Tickets fits
A knowledge base, live chat, satisfaction surveys and asset management are not on its feature list. ASL Messaging handles quick back-and-forth; Tickets handles the thing someone has to finish.
Where ASL Tickets fits
If you already run a product that carries it, the request panel is included. For software you run yourself, it is quoted. If your team needs the bigger features now, a larger help desk may fit better. If you need a shared, owned record of who asked for what, ASL Tickets covers that.
Rolling out help desk ticketing software in a small team
Choosing a tool is the easy part. Most of the value of help desk ticketing software comes from a few habits the team agrees on in the first month. The steps below suit a small office or operations team, whatever tool you pick.
Rolling out help desk ticketing software in a small team
Start by naming one owner for the queue. That person does not answer every request. Their job is to look at new requests each morning, make sure each one has a name on it and chase anything that has sat untouched. Pick a backup for days off. Without a named owner, unclaimed requests pile up quietly.
Rolling out help desk ticketing software in a small team
Keep categories few. Five or six broad groups, such as equipment, accounts, facilities and billing, are enough to spot patterns. Long lists slow people down, and requests end up filed under “other.” If your tool has no category field, a consistent word at the start of each subject can do the same job. Agree on the list together and review it after a few months.
Rolling out help desk ticketing software in a small team
Set response-time goals as a team, not from a vendor template. Think about what people need in practice. A locked-out employee may need help within the hour, while a request for a new chair can wait a week. Write two or three plain goals, such as “first reply within one working day,” and check them by hand at first. Goals the team helped write are goals the team keeps.
Rolling out help desk ticketing software in a small team
Write replies people can reuse. When the same question comes back three times, turn your clearest answer into a short saved reply. Keep each one plain: what to do, where to click and who to call if it does not work. Store them in a shared document the whole team can edit. Over time, the most useful answers can become a simple help page for the people who file requests.
Rolling out help desk ticketing software in a small team
Review ticket volume once a month. Count new requests, closed requests and requests still open, by category if you have them. Look for the request that keeps coming back. Three tickets a week about the same printer is a reason to fix or replace the printer, not to answer faster. Keep the review short, write down one change and check next month whether it helped.
Rolling out help desk ticketing software in a small team
Close the loop with requesters. Before you mark a request resolved, tell the person what was done and what to do if the problem returns. If the answer is “no” or “not now,” say why and when that might change. People who hear back keep using the queue. People who do not hear back go back to texts and hallway requests.
Rolling out help desk ticketing software in a small team
If your team uses ASL Tickets, its five states (open, in progress, waiting, resolved and closed) give these habits a shared vocabulary, and the person who filed a request can watch it move. It has no service-level timers or categories, so the queue owner checks goals and patterns by hand.
Read the guide
IT Ticketing System for Small Business: Buyer's Guide
Read the guide
A practical guide that uses public, official sources and explains where this product fits and where it does not.