BackboneAtlas
Book a demo
Guidance built in

The system explains itself, so nobody has to be trained on it.

Everyone else sells an implementation project and a training budget, then the team writes a manual that goes stale. Atlas generates the manual from live configuration — one guide per role, screen by screen, quoting your real thresholds — and puts the page in a drawer on the screen you are on.

Why it is generated

A manual written once is wrong by the second quarter.

Guidance goes stale because it is written by hand, away from the system it describes. These read the same tables the enforcement reads — so a guide cannot say 75,000 while the system enforces 50,000.

  • LiveEvery figure comes from one function, so the guides, the policy page and the rules page cannot disagree with each other or with the product
  • YoursThe text branches on whether you buy as a public or a private body. Guidance written for a public buyer is actively misleading for a private one, so it is not shown to them
  • RegionalVocabulary follows the jurisdiction: a Gulf reader sees grievance where a Canadian reader sees challenge
  • HonestEvery surface says on its face which parts are generated and enforced, and which are general practice for you to adapt
.../guides
Role guides — One guide per role — nine of them — each exportable to Word.
Role guidesOne guide per role — nine of them — each exportable to Word.
What do I do

Screen by screen, with the reason it is done that way.

A step that only says what to click teaches nothing. Each says what to do, why it is done that way, and the edge cases people get wrong — the part that stops work bouncing back.

  • WhatThe action, on the screen it happens on
  • WhyThe reason the control exists, so it is followed rather than resented
  • EdgeThe cases people get wrong: what a rejected request keeps. Why a requisition cannot be edited after submission. What an empty queue does and does not mean
  • ExportAny guide downloads as a Word document, to adapt and issue as your own procedure
.../guides/requester
A role guide — The requester's guide: what to do, why, and what people get wrong.
A role guideThe requester's guide: what to do, why, and what people get wrong.
Where has this got to

The processes, drawn across every pair of hands they pass through.

A role guide answers "what do I do". It cannot answer "why is this stuck", because that is usually inside somebody else's job. Eighteen process guides follow a purchase across every role that touches it. A route map add-on, off by default, draws every path from request to paid invoice as flowcharts, and says where a regime is not modelled rather than guessing.

  • EighteenTwelve core — from a need to an order, from an order to a payment, running a competition, when an invoice is due and more — plus construction, one for each of four sector packs, and one on units and landed cost
  • Drawn, not just describedEvery guide opens with the flow drawn from its own stages, HANDOVERS marked — where work changes hands, and where a process actually stalls. Generated from the stages, so the picture cannot drift from the words
  • Each stageNames the screen, the person, what happens, and what the system does about it without being asked
  • Regime-awareA public buyer's stages carry the posting period and standstill; a private buyer's do not, because they do not apply
  • ExportableEvery flow downloads to Word, carrying the disclosure that the figures are generated and the guidance is yours to adapt
.../flows/when_you_get_paid
A process guide — The flow drawn from its own stages, handovers marked, above the stage-by-stage explanation.
A process guideThe flow drawn from its own stages, handovers marked, above the stage-by-stage explanation.
Which way does this purchase go

Every route from a request to a paid invoice, drawn.

The route you choose is not a label on the same process: it changes what happens next. The route map draws each route as its own track, for your region and your kind of buyer, and the tracks meet only at the purchase order. It is an add-on, off by default.

  • GeneratedDrawn from the flow definitions inside the product, so the picture follows the rules the system applies
  • Read by shapeA diamond is a decision, a D is a wait nobody may shorten, a cylinder is evidence that outlives the transaction
  • Region and buyerChoose the region and a public or private buyer. The United States and Australia offer the private buyer only, because their public rules are not modelled
  • Gaps hatchedA step the flow needs and Atlas has not got is drawn hatched: named, not glossed
.../routemap
Procurement route map — A Canadian private buyer's goods routes, each drawn as its own track.
Procurement route mapA Canadian private buyer's goods routes, each drawn as its own track.
What are the rules here

The purchasing policy nobody had to write.

Most organisations keep a purchasing policy in a document describing what somebody intended. This one is generated from what the system actually enforces, so policy and practice cannot drift apart.

  • One pageWhat happens at what value, in plain language, for the person who just wants to buy something
  • By purchaseThe rules page answers the narrower question — what governs a purchase of this type at this value
  • Trade agreementsWhere you buy as a public body, coverage, minimum posting periods and standstill are stated as obligations, with the agreement that creates each one named
  • Never guessedWhere no thresholds are configured for a jurisdiction it says so, rather than implying there are no obligations
.../policy
How buying works — The purchasing policy, generated from the live configuration.
How buying worksThe purchasing policy, generated from the live configuration.