Two ways to score a bid
Most companies weigh a bid along several separate angles: can we formally take part, are the contract terms acceptable, is the deal worth the money, does the work fit what we do, and how well do we know this buyer. In Realm those angles are called analysis dimensions, and you define them yourself.
An administrator sets up dimensions in Settings > RFP settings. See Go/No-Go analysis dimensions for how to create them. Until someone does, Realm uses the standard analysis described in Analysis without dimensions.
Running an analysis
1
Add the tender files
Upload the buyer’s files to the project. The analysis reads every project
file, questionnaires and supporting files alike. If any file is still
being processed, Realm warns you before it starts, since the analysis
cannot cover a file it has not read.
2
Start the analysis
Select Run analysis. Realm reads the requirements out of each file,
then works through them: with dimensions, it scores each dimension in turn
and writes the recommendation at the end. The page shows the steps as they
complete.
3
Read the result
The Overall summary page leads with Realm’s recommendation and the
reasons behind it, followed by each dimension at a glance and the written
analysis in sections you can fold and unfold. The analysis cites the
sources it used.
Types of requirement
Realm sorts every extracted requirement into one of four types.
Commercial terms and procedural items are never judged or scored, whichever analysis runs. They are listed for reference and feed the project’s checklist of what the bid owes the buyer. Qualification and capability requirements are the ones the analysis works on.
Dimensions that read the tender
A dimension judges extracted requirements against your knowledge base (each in its own evaluation, or a small related set in one investigation) or reads the tender documents themselves and writes one assessment. Nobody picks which: each analysis run reads the dimension’s instructions and the tender’s requirements and decides, as described in RFP settings. A document assessment has its own page like any other dimension, with its conclusion and findings, and no requirements table, because it scores no requirements. When its instructions only ask for reporting, the run leaves it unscored: the page says it is context only, the Fit dimensions list shows no score for it, and the recommendation treats its findings as background rather than as a judgment of your fit. One reading can only cover so much text, so a large tender is read in parts: each part’s findings are collected, and the assessment is written from all of them together, covering every document. Only an extremely large tender can exceed what the parts hold; when one does, each dimension picks the documents most relevant to what it assesses and reads those first. The dimension’s page lists what it read under Read from, and anything left out under Not read, so you can see what the conclusion does and does not cover.The pages of a dimension analysis
With dimensions configured, Go/No-Go analysis in the sidebar heads a list of pages:- Overall summary, the recommendation and the memo.
- One page per dimension, in the order set in settings, each with its score beside it.
- All requirements, every extracted requirement with the verdicts each dimension gave it, grouped by file. Search it, or filter it by how critical the tender makes a requirement. A requirement no dimension picked up reads Not scored in any dimension.
Overall summary
A line under the title says what the analysis rests on: when it was analyzed, how many dimensions were scored, and how many requirements and tender files it read. The card at the top answers whether you are bidding. Until your team records a decision, Realm’s recommendation leads it, labeled Realm recommends, with the outcome, a one-line headline, and the reasons behind it. Once a decision is recorded, the decision leads and the recommendation sits beneath it as the context it was made against. If any dimension found blockers, the card lists them under the dimension that found them. Select a dimension’s name to open its page. Once a decision is recorded, the list folds under a line that counts the blockers. Select the line to show the list again. Fit dimensions lists every dimension with its score, and how many blockers and open questions it found. Select one to open its page. Below that, the written analysis is laid out in folding sections. Expand all opens them together.A dimension’s page
Each dimension has a page of its own. Before a run, it shows What this dimension assesses, which is the instructions an administrator wrote for it. While the analysis runs, it says where the dimension is, from selecting the requirements that fall under it, through scoring them, to summarizing. After the run it shows:- Conclusion: the dimension’s written summary.
- Blockers: the findings that put this dimension at risk.
- Strengths: the findings that support the bid.
- Open questions: the requirements your knowledge base held nothing about.
- Requirements: every requirement the dimension scored, worst verdict first, with the buyer’s must-haves first within a verdict. Filter by verdict, and select a requirement to read the reasoning and the sources behind it.
Realm weighs each requirement by how critical the tender makes it, so a failed must-have drives the score down much further than a failed minor requirement. Requirements with no evidence never count against the score.
A requirement can belong to more than one dimension, because the same clause can be both a legal and a commercial concern. A requirement that no dimension needs is skipped.
Each analysis has a fixed number of requirement judgments to spend, the same number it would spend with no dimensions configured, and the dimensions share it. On a large tender that means a dimension judges the requirements it most turns on rather than every requirement it could claim, and a dimension that needs only a few leaves the rest of the budget to the others. Adding more dimensions therefore sharpens what each one looks at instead of making the analysis read more.
With dimensions configured, you can override a verdict: open a requirement from a dimension’s list and use the Reviewer override section, choosing Pass, Partial, Fail, or No evidence. The override belongs to the requirement, so it outranks the verdict in every dimension that judged it, and it survives re-runs. Verdicts and their counts update as soon as you save; the dimension scores and the written analysis update on the next run, so the page marks them out of date until you re-run.
With dimensions configured, re-evaluating a single requirement and
regenerating the written analysis on its own are not available. To redo an
analysis, re-run it.
Analysis without dimensions
When no dimensions are configured, Realm runs its standard analysis on a single page. It answers two questions: whether you meet the formal conditions for taking part, and how well your capabilities match what the buyer wants. Qualification requirements form the eligibility screen and never count toward the score. Capability requirements produce the score.Can we bid?
The Can we bid? panel collects every qualification requirement that needs attention, worst first, with the file it came from.
A failed qualification only counts as a blocker when the tender makes it a condition of taking part. Other failures are gaps. Hard blockers come first in the list, because they decide the question on their own.
Select a finding to open it. The dialog shows the requirement, the evidence Realm found, and the sources behind the verdict. Previous and next controls step through the whole list without closing the dialog, and resolving a finding moves you to the next one, so you can work through the panel in one pass.
Solution fit score
Capability requirements produce the solution fit score, rated from Very Low to Very High. Each requirement counts according to how critical the tender makes it, from Must-have down to Minor. The score counts only the requirements where your knowledge base held evidence one way or the other. Requirements with no evidence are shown as No evidence and do not count against you. If nothing could be scored, the page says so instead of showing a number. The caption under the score says how many capability requirements were scored, and how many were left out for lack of evidence. Below the panels, requirements are grouped by the file they came from, so you can open a file and read every verdict in it. By default Realm leaves the least critical requirements out of the evaluation to keep it fast. To include them, open the menu on the Run analysis button and choose Run on every requirement.Overriding a verdict
When you know better than the analysis, open the requirement and use the Reviewer override section of the dialog. Choose the verdict yourself: Yes, Partially, No, or No evidence. For a failing qualification you also set whether it is a resolvable or a hard blocker. Every override needs a written reason, an evidence document, or both, and then Save override. An uploaded document also joins the project’s files, so the rest of the team can see it. Use Edit override to revise yours later, or Clear override to hand the requirement back to Realm’s verdict. The score updates as soon as you save, and Realm’s original verdict stays visible next to yours. Once verdicts have changed, the page offers Regenerate analysis, which rewrites the written analysis from where the verdicts now stand.Recording the bid decision
Realm states a recommended action, Go, No-go, or Improve position, with the reasons behind it. The recommendation is advice. Once your team records its decision, the decision leads the card and the recommendation sits beneath it as the context it was made against. Select Decide on a dimension analysis, or Record decision on the standard one. Choose the outcome (Go, No-go, or Improve position) and add a note if you want to record why, or on what conditions. The note is optional. The dialog marks which outcome Realm recommends and says what each one does to the project’s status. You cannot record a decision while an evaluation is still running or while the analysis is being written, so the decision always rests on a complete assessment. A decision keeps a frozen snapshot of the assessment it was based on, and every past decision stays visible under earlier decisions, so you can see what was known at the time. If the assessment changes afterwards, a notice says the decision may be outdated. To change course, record a new decision. The decision also sets the project’s status:
A No-go project stays in the RFP list under its own status instead of being archived, and all three statuses can be used as filters there.
Keeping the analysis current
A notice flags the analysis as possibly outdated when the project’s documents change, when the linked tender notice is superseded by a newer version, when the submission deadline changes, or when the project’s tags change. On a dimension analysis, the Re-run menu offers two ways to redo it:- Re-run analysis scores again from the requirements Realm already read.
- Read files again and re-run starts from the files, for use after the project’s files changed.
Reading the analysis in another language
To read the summary and the Go/No-Go analysis in another language without changing them, pick a Display language at the top of the Analysis sidebar. Realm translates the text for you and keeps the citations on the right sentences. A Translated tag beside the summary or analysis title shows what you are reading is a translation. Quotes from the buyer’s documents stay in their original language. The display language changes only what you see. Other people still see the analysis in the project language, nothing runs again, and scores and verdicts stay the same. Realm remembers your choice for the project in this browser and translates again when the analysis changes. Exports and printed summaries use the project language. In the standard analysis, re-running discards reviewer overrides, so Realm asks you to confirm first and says how many would be lost. Changing a dimension in settings does not change analyses that already ran. Re-run the analysis to apply the change. A re-run replaces the dimension results as it starts, so if it fails, run it again rather than expecting the earlier results to come back.Comparing with a previous round
If your company bid on an earlier round of the same tender through Realm, link that project as the previous round from the project header. Realm suggests likely candidates based on matching requirements. The comparison is available in both analysis views: as its own sidebar section in the dimensions workspace, and as a card with a View details dialog in the classic analysis. If the earlier round never went through Realm, compare against its files instead. From the same popover, choose Pick a knowledge folder to link a knowledge base folder holding the old round’s files, or Upload a .zip to upload them as an archive. An uploaded zip is extracted into a shared knowledge folder named after the archive, and Realm links that folder once the files finish processing. The comparison reads every document in the linked folder, parsing its spreadsheets so the file-by-file diff works the same as between two Realm projects. Reviewer comments only exist for rounds run in Realm, so a folder comparison has no feedback grading. Previous round comparison then appears in the Analysis tab’s sidebar, with four pages listed under it while it is open:- Overview: a headline and a short read on what the buyer rewrote, a few points on what the round means for your bid (the work ahead, the biggest risk, what got easier, and what became of your feedback), how much of your previous work carries over, the themes behind what changed, and a summary of your feedback. Beside it, About this comparison names the round it compares against and when it ran. Every count opens the list behind it, so selecting Reworded opens the reworded requirements.
- Our feedback: each point your team raised last round and whether this round took it up.
- Requirements: every requirement of this round matched against the last one.
- Files: every compared file, each opening to its own changes.
How much carries over
The overview counts this round’s requirements as unchanged, reworded, or new, each with what it means for the bid: an unchanged requirement means your previous answer stands, a reworded one means starting from that answer and checking it, a new one means there is nothing to start from. The previous round’s questions that are no longer asked are counted apart, since they are not part of this round’s total. Two sets of counts appear on the page and they are not the same population. The requirement counts are matched across the whole round. The per-file counts are rows of each file. The page labels which is which, and they do not add up to each other.What changed
Rather than list thousands of individual edits, Realm groups them into at most five themes and ranks them by how much they affect your bid (for example, every integration becoming its own requirement, or a scope statement naming a priority it did not name before). Each theme is a card with what is at stake and one change quoted from the files as it reads in both rounds; the first two start open. Theme sizes and quotes come from the files themselves, so they cannot drift from what the diff found.Our feedback
If your team commented on the previous round’s rows, or answered a comment-form questionnaire, the comparison grades each of those points on whether this round takes it up: taken up, partly taken up, not taken up, or cannot tell from the documents. The list opens on the points not taken up; the filters switch to the other grades. Opening a point shows what you asked, what this round did with it, and why it got that grade.Files
The files are listed busiest first, each with its changed, new, and gone row counts. Opening a file lists its individual changes, filtered by kind:- A changed row names the column that changed and shows the old and new value, for example a transfer method changing from real-time to SFTP, or a scoring class moving from V1 to V2.
- Rows added or removed together, such as a whole service area dropped from a price form, collapse into one line with their row range instead of dozens of entries.
- A row that reappears on another sheet shows as moved, and a row folded into a wider requirement shows as merged, with the surviving text.
- The same new or removed row appearing several times is listed once with a count.
- Sheets renamed between rounds are paired anyway. Supplier answer and score columns are left out of the comparison, and About this comparison says which.
Requirements
Requirements pairs each of this round’s requirements with the question it came from, filtered by what happened to it: reworded, new, no longer asked, or unchanged. It opens on the reworded ones. Opening a requirement shows its wording in both rounds and any comments your team left on that question.Keeping the comparison current
Linking or changing the previous round after an analysis exists refreshes only the comparison, not the written analysis. To fold the previous round into the analysis text, re-run a dimension analysis, or select Regenerate analysis on a standard one. If a file in either round changes later, the comparison is flagged as out of date under its title, and Re-run compares the rounds again.This is different from basing an RFP on a previous
round, which copies
answers from a previous questionnaire into a new one. The comparison here
informs the bid decision and copies nothing.