A CONTROLLED REQUEST REVIEW
Review incoming estimate requests with their original context
Work from the customer’s submitted answers, selected offerings and contact details, then move the request through a controlled review and quotation process.
Receive a brief that can be assessed
A request workspace should help the team understand what the customer asked for before it decides what to offer. Tsumira keeps the submitted questionnaire context, selected offering snapshots and reachable contact details with the request. The team can assess scope and pricing uncertainty without rebuilding the original form from memory. The request remains distinct from an issued quotation revision, a financial document and a confirmed payment.
Keep the evidence behind the request
The intake records the published wizard version and its content reference, customer answers, selected offering context and consent to the supported submission terms. Price preparation resolves the supported catalog on the server instead of trusting client-supplied totals. Duplicate submission protection distinguishes a retry from a new semantic request. These controls support reliable intake, while the team still checks whether the customer’s description is sufficient for commercial review.
- Original wizard and offering context
- Server-resolved supported pricing
- Protection for repeated submissions
Use statuses with a clear meaning
The request distinguishes new, reviewing, quoted and closed. A reviewer can move an eligible request into review or close it through the supported transitions. Quoted is reached by issuing a real quotation revision, rather than simply applying a label in a dropdown. The current transition model does not reopen closed requests. Use the states to describe actual progress and keep the next action understandable to colleagues.
- New and reviewing stages
- Quoted tied to an issued revision
- Closed is not silently reopened
Coordinate changes against the current version
Status and issuance operations check the expected request state and revision. This prevents an operator working from an older view from silently replacing a colleague’s newer decision. When the state has changed, refresh and review the current request before proceeding. Decide who should clarify missing details, who may issue the commercial response and when a request should stop progressing. Permissions and current-state checks complement that human responsibility.
- Current-state checks
- Concurrent review changes detected
- Responsible next action
A concrete workflow
Open the request
Read the submitted answers, selected offering context and contact route.
Assess the brief
Identify missing scope information and the actual pricing review required.
Take the supported action
Move into review, issue a real revision or close the request as appropriate.
Check the outcome
Confirm the current state and retain the request’s connection to later quotation work.
An illustrative working example
Example: two colleagues review one request
One colleague starts reviewing a new request while another prepares its commercial response. The expected-state check prevents the first colleague’s stale action from overwriting a later quotation decision. The team refreshes the current record and sees the issued revision behind the quoted state. If essential details were missing instead, it could keep the request in review and clarify them before issuing anything.
Questions about this topic
Is a received request already a quotation?
No. It records what the customer submitted. An issued quotation revision is a separate, deliberate commercial action.
Can we manually label an unpriced request quoted?
The quoted transition is tied to issuing a real revision. The status should not represent a quotation that does not exist.
Can a closed request be reopened?
The current supported transition model keeps closed requests closed. Do not assume a reopen action is available.
What if a colleague changes the request first?
Operations check expected state and revision. Refresh the current record and review the new situation before retrying.
Explore connections around this workflow.
Ideas for intended connections. Check the actual availability, permissions and supported data for each app before using a scenario.
Salesforce
Workflow concept: Compare the submitted request brief with external account context before choosing the next review action.
Slack
Workflow concept: Coordinate who will clarify a missing requirement while keeping the request’s actual state authoritative.
Outlook
Workflow concept: Prepare a clarification response using the request’s real contact route and original scope.