Somebody is halfway through a requisition and does not know which category to pick, whether they need three quotes, or why the system refused them. What happens next decides whether the software gets used or worked around. Atlas answers four ways; three never involve us.
"What am I supposed to do here?" arrives mid-task, and nobody stops to open a manual. So the guidance is on the screen that prompted it — a panel that opens beside the work and closes again.
It is specific to that screen and to the person's role: an approver and a requester on the same page are told different things. Written for people who did not choose this software and do not care how it works.
The biggest source of support load in any procurement system is a rule nobody understands. So every refusal names what was wrong, what the limit is, and what to do next. A test fails the build if a route refuses silently.
Your buying policy, thresholds and procedure pages are produced from the rules the system actually enforces. They cannot drift from behaviour, because they are the same source.
An ask too vague to action comes back with the specific question that would make it actionable — not silently converted into a requisition somebody unpicks later.
An ask belongs to the team, not to whoever was asked. It is visible, assignable and answerable by anyone with the standing to answer it — so a holiday does not become a bottleneck.
Most questions are not about the software. They are "can I buy this?", "who approves it?", "is there a contract already?" — and in most organisations they arrive as a tap on the shoulder, a direct message, or a buried email.
Ask procurement is where those go instead. It is on every screen, it keeps the thread with the answer, and the answer becomes findable rather than living in one person's sent items.
When something is wrong — a screen unclear, a number off, a rule firing that should not — whoever noticed raises it from the screen they are standing on. No leaving Atlas, no second login, no email describing their own environment.
The support desk is not a licensed module or a paid tier. Every workspace has it, on every plan, from day one — a customer who cannot reach us stops using the product and never says why.
Every ticket gets a short reference to quote and a state in plain words — Open, Triaging, Waiting, Answered, Resolved, Closed. Not an internal queue code, and not silence.
Tickets raised by anyone in your workspace are visible to your own IT Administrator on one screen. You are never in the position of asking us what your own people have reported.
"I have a question", "something isn't working", "a number looks wrong", "I'd like it to do something it doesn't". Nobody confused by a screen classifies their own problem as a defect, so we do not ask them to.
A how-to, a field nobody explained or a refusal nobody understood gets a guided answer, drawn from your workspace's own guides. Anything that needs a change to code or data goes straight to the people who build Atlas. No call centre, and no partner in between.
Triage reasoning and diagnosis are kept out of the conversation you see, so a thread reads as an answer rather than somebody thinking out loud.
Every other system opens the same way: "which screen? which version? what did you click?" — a round trip that costs a day, and that people rarely answer accurately. Atlas captures it at submit, automatically.
| Captured with every ticket | Why it matters |
|---|---|
| The screen they came from | A ticket opened from a page that misbehaved records that page. Nobody has to describe it, and nobody misremembers it. |
| The exact build and schema | "You were on that release; this was fixed in the next one" is often the whole answer — and it is available before anyone reads the ticket. |
| The browser and device | The class of fault that only happens in one browser stops being a mystery. |
| A correlation id | Joins the ticket to what that session actually did in the minutes before it — which turns "it's broken" into a reproduction. |
Not keystroke logging or session recording — the diagnostic trail the system already keeps for its own errors, tied to the ticket by an identifier. It exists whether or not a ticket is raised, and is kept for the retention period your administrator sets. Periods ship unset, so until one is set it is kept.
Beside the support button is a second one that does something deliberately smaller: it sends us a note, and nobody replies.
That sounds worse until you notice what a ticket costs. A ticket carries a reference, a status and a promise that somebody answers — and that promise is what stops somebody sending "this list would be easier to scan sorted by date." Not worth a case, so it goes unsaid: the most useful thing we would have heard that week.
So the second channel exists: one line, one click, and the form says plainly, before you type, that we read everything and will not reply there.
There is no reply route, no status and no reference number anywhere in it — not as a policy, but because none was built. A promise you cannot accidentally break.
From a company this size that is a statement rather than a slogan: no product council sits between your buyer's remark and the person who decides what gets built.
Every other page on this site states what Atlas does and lets you check it in a demo. This section is the other half of that habit.
We grade tickets by severity and commit to a first human response: 2 business hours if nobody can sign in or data is at risk, 1 business day if a significant function is unusable, 3 if there is a workaround, 5 for a question. The same targets are in your agreement.
Backbone is a small company, incorporated in British Columbia, and the desk keeps Eastern business hours: 09:00–17:00, Monday to Friday, excluding Canadian statutory holidays. A code or data change reaches the people who wrote the code, which is worth a great deal. You do not get a follow-the-sun rota — worth knowing before you sign, not after.
Ask procurement is a front door to your procurement team, not an IT service desk for the organisation. It deliberately refused to become one — a general ticketing tool would have been a worse version of something you already own.
Break something on purpose, raise it from the screen it happened on, and watch what the ticket already knows. It takes about a minute.
Book a demo