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 a questionnaire is
still being processed, Realm warns you before it starts.
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 either judges each extracted requirement against your knowledge base, or reads the tender documents themselves and writes one assessment. Nobody picks which: each analysis run reads the dimension’s instructions 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 assessment can only read so much text, and a large tender can exceed that. When it 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, a line counts them across the dimensions. 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, reviewer overrides, 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, or when the submission deadline changes. 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.
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. Previous round comparison then appears in the Analysis tab’s sidebar. It opens with an Overview card: a headline and a short read on what the buyer rewrote, and how much of your previous work carries over. Beside it, About this comparison names the round it compares against, when it ran and whether it still matches the files. Below, the comparison is grouped into sections made of cards you can fold: what changed, feedback from last round, files compared, set aside, and requirement by requirement. While the comparison is open, its sections are listed under it in the sidebar, each with what to know about it, such as how many points were not taken up. Select one to jump there; Expand all and Collapse all open or fold every card at once. The comparison is context, not a verdict. It colors the written analysis but produces no score of its own.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.Feedback from last round
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 into account, partly, not at all, or cannot tell from the documents. The section opens with how many points fall under each grade, then one card per grade listing each point, what this round did with it, and why it got that grade. The points this round ignores are open first; the other grades start folded.Files compared
A table lists every compared file with its changed, new, and gone row counts, busiest file first. Opening a file lists its individual changes:- 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.
Set aside
Changes that the totals count but that are not worth reading one by one are grouped and named rather than dropped: edits that reword nothing (spacing, list numbering, punctuation), rows that only moved between sheets or merged into a wider requirement, and the rows of files only one round has, such as a market-dialogue form that this round does not use. Each group opens to the changes behind it.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.