Requirements

Once a customer has raised a request, they write its requirements in a conversation with the Sustentus assistant — the customer’s Project Discovery register in the agentic app. The platform hands them to it: the request’s next action reads Complete customer conversation, and following it opens the conversation about that request, which the assistant starts itself.

Flow

The conversation

The conversation belongs to the request: opening Complete customer conversation again, from any tab or later, returns to the same conversation rather than starting a new one. The assistant speaks first — it shows the document as the platform holds it, says it will work through it with the customer, and asks about the gap that matters most. From then on it asks one thing at a time, often with a short set of clickable answers (a single choice or a checklist) the customer can pick from or type over.

It works on the same document from the same lead record — the field rows it holds, how many carry a value, and what is still open — plus the customer’s own requests by stage and where one has got to on the journey.

It writes the two sections the document is made of as the conversation goes along:

• Overview — the problem in the customer’s own words: what is happening today and why it is worth paying to fix
• Requirements — what the work must deliver, most important first (must have, should have, nice to have)

It also records the request’s own rows as the customer gives them: what they need, their industry, where the work happens, the languages and when they need it.

The customer is never asked for a budget. The budget is the service’s price: the document shows a Service price (from the catalogue) row beneath the service, read from the service’s list price in the catalogue every time the document is shown — on the draft from the moment the service is chosen, and after approval — in the price’s own currency (for example £5,000, or £1,500 / month). A service with no list price reads Not yet priced. A request that holds a budget a customer gave before this rule shows the service’s price too; the figure it holds is kept but no longer shown. The row is never counted and never open: nobody records it.

• Industry is always one of the workspace’s own industries. When the answer does not match one, the assistant offers the closest few to choose from and never creates a new one.
• Where takes a country from the standard list or one of the workspace’s regions. A country’s region is filled in for it.
• When you need it needs a start date; the end date is optional. A start in the past is refused.
• A customer who does not know their timing yet is offered approximate choices (“within a month”, “next quarter”). The pick is saved as a real date. “Not sure” is never saved: the row stays open until they pick.
• Languages keep the request’s default unless the customer raises them.
• Service and product are set when the request is raised, and the assistant never changes them.

All of it lives as an unconfirmed draft of its own until the customer submits it, so a half-finished conversation never reaches the request. A value the assistant cannot save comes back to it with the reason, and the other answers in the same turn are still saved. A section the assistant worked out rather than being told is shown as inferred with the reason beside it, and the customer correcting it in conversation takes the marking off. The rows are only ever recorded from what the customer said or picked.

Only a complete document can be submitted. All nine rows must be recorded: what you need, service, product, industry, where, languages, when you need it (a start date — an end date alone is not enough), the overview and the requirements. The card counts those nine (“6 of 9 recorded”); the service price sits beside them and is never counted. Until they are, the document card names the rows still open, the assistant asks for them one at a time, and it does not offer to submit. A request that holds only an end date shows it on the card, marked as missing its start date, and that row still counts as open. The platform refuses an incomplete document whoever submits it, on the first approval and on every later version, and writes nothing when it does. An open service or product is changed by the customer’s Customer Success Manager, never in the assistant.

Submitting checks the drafted answers again. What the customer drafted was checked when they said it, but the platform can change before they submit: a start date passes, an industry is retired, a region is renamed or removed. So the answers are checked again at submission against the platform as it stands that day. If one no longer holds, nothing is submitted: the assistant names what changed, that answer is cleared from the draft and shows as open again, and the assistant asks for it before offering to submit once more.

Submitting is the customer’s own act and cannot happen by accident: the assistant asks, the customer authorises that specific request, and the document is then approved. The drafted rows are written onto the request in the same step, the request is released to the expert bid pool and moves into bidding, and the approval is recorded on the activity trail. The approval writes no budget onto the request: until an expert’s quote counts, the request is valued at its service’s list price — the one-off price, or one month of a monthly one — read live from the catalogue in its own currency, and the expert’s bid pool shows the same price. The assistant tells the customer what comes next in the same words: the document goes straight to the bid pool, and the experts matched to it are told. Back to your request, in the assistant’s header, returns them to the request on the platform.

Where a workspace has no assistant configured, the request offers no conversation and its requirements page says the assistant is not configured.

The approved document on the request

Once the document is approved, the request’s Requirements section on the Customer Service Journey shows the same rows the customer approved in the assistant, in the same order and words: what you need, service, the service price (from the catalogue), product, industry, where, languages and when you need it, then the overview and the requirements. A row with nothing recorded reads Not recorded, and a request holding only an end date shows it marked as missing its start date. Before approval the section shows the overview and requirements as it always has.

Requests approved before every row had to be recorded may still have rows open. The CSM, the SDM and admins see a warning at the top of the section naming them, for example Approved with rows still open: industry and where. Ask the customer for them. The service price is never named — it comes from the catalogue. Nothing on the platform fills those rows after approval, so the warning says what is missing and who to ask. The customer, experts and vendors see the rows without the warning. A complete document shows no warning. On a moment of the request’s history the rows and the warning read the request as it is now, since only the overview and requirements are kept per version.

The conversation record

The request’s Requirements section on the Customer Service Journey shows the conversation beneath the document, read-only: every turn in order with who said it and when, what the assistant showed, and each question it asked with the answer the customer gave. Nothing on it writes — the conversation is only ever continued in the assistant.

The customer sees their own conversation there, and so does the team who hold the requirements at full scope — the CSM, the SDM and admins. Experts do not: they quote against the approved document, not the conversation behind it. On a moment of the request’s history the record shows the conversation as it stood then.

The document is versioned, and the customer’s own words are kept

Approving does not overwrite anything. It writes the overview and requirements as a new numbered version of a document of its own, held against the request and recording who approved it, when, and whether it came from the agent or from a person. The request points at its latest version; earlier ones are kept and listed beside it.

The request’s own description — the few lines the customer wrote when they raised it — is never touched by any of this. It stays as they wrote it, and every surface that shows the requirements shows it underneath, under Customer’s request, so the document and the ask it came from can always be read side by side. A request with no approved BRD yet shows that description on its own, as it always has.

Correcting a document is therefore a new version rather than an edit: a CSM or SDM using Edit overview on the workspace writes the next version, and the one before it stays readable. So does the customer approving the document again. A correction does not release the request again: it stays in the bid pool, nobody is matched again, and every quote stands as it was priced. What changes is that each expert whose quote is still open — a draft, submitted, or sent back for changes — is told the requirements were revised, with a link to the request, so they can read the new version and update their quote if it no longer fits. Experts whose quote was accepted or rejected are not told, and nobody is told once the request has been awarded or has left the bid pool. A request whose BRD was approved before versioning existed carries a version 1 built from what was stored, and shows no Customer’s request section — their original wording was overwritten at approval, before any of this existed, and cannot be recovered.

From approval to the bid pool

The customer’s approval is the release. There is no separate review and no SDM step between the customer and the experts: the moment the customer approves a complete document, the request enters the bid pool. The Requirements section of the Customer Service Journey shows both with when:

When the customer approves, the lead moves through backlog into bidding, ownership passes to its CSM, and the platform matches the experts — those who list the lead’s product and have room under the active-project cap — and ranks them (Expert matching). It then notifies every matched expert, and anyone an SDM added by hand, once; an expert added by hand later is told there and then. The customer’s confirmation waits for that matching before it answers. The SDM’s work starts in the bid pool — watching quotes, answering expert questions, the quote-threshold alerts.

The approval gives the request its SDM. A request with no SDM is handed to the active SDM carrying the fewest requests from bidding through the survey (ties go to the longest-standing SDM), and that SDM is told it is theirs; the hand-over is on the request’s activity like any Assign SDM. A request that already has an SDM keeps it, and a later approval of a corrected document changes nothing. With no active SDM the release still goes ahead and the request waits for Assign SDM — nothing assigns one later, delivery included.

Only a request that has not reached bidding is approved. The first approval is accepted while the request is pending or in backlog. A request already further along — bidding, quote review, delivery, delivered or closed, such as one a CSM moved on by hand before any document was approved — is refused: the assistant will not draft or submit a document for it, says that changes now go through the CSM, and the platform refuses the approval itself whatever calls it, so nothing is written and no expert is told. A corrected version of a document that is already approved is not affected.

The pool opens with time to quote. A lead’s bid pool deadline is set when the lead is created, so a request can be approved after that deadline has passed, or with less than 48 hours to go. Opened like that, the daily bid pool deadline sweep would warn its CSM at once and close it before anyone could quote. So when the deadline has passed or is within 48 hours, the approval moves it to seven days after the approval, in the same step. A request whose deadline is further out, or that has none, keeps it.

Beside those two states, the approved BRD shows the required skills recorded on the request and its Service Pipeline Value — the same figure the journey header and the Overview show.

A request released by an SDM before the approval became the release shows that SDM as who released it; one released before either was recorded shows the platform. Requests that were approved and still waiting on an SDM when the change shipped were released to the bid pool by the platform then, with the same deadline rule; their matched experts are told the next time the platform notifies for that request.

Exception Handling