A spreadsheet can hold the exact detail visitors need, and the ambiguity that produces the costliest support answer. A price in a cell may depend on a product variant, unit, region, contract term, tax status or date. Preparing an Excel file for a chatbot means making those dependencies explicit before anyone asks a natural-language question.<\/p>\n
Do not begin by uploading every worksheet. Separate customer-facing lists from planning models, internal margins, supplier notes and drafts. Give each accepted sheet an owner, effective date, currency, market and approval status. A clean source boundary is the first protection against a chatbot quoting a figure that was never meant for a visitor.<\/p>\n
RobiFox accepts Excel documents and describes price-list material becoming tabular knowledge rather than a wall of text. That does not mean a live spreadsheet connection: treat an upload as a versioned source and replace or pause it when the business issues a revision.<\/p>\n
One row should represent one meaningful offer or rule. Put a header over every column and include units in the header where possible: Price (EUR, excl. VAT)<\/em>, Minimum order (kg)<\/em>, Dispatch window (business days)<\/em>. Avoid colour-only meanings, merged decorative headers, hidden conditions and formulas whose result changes with a private assumption.<\/p>\n RobiFox\u2019s price-list interface separates table-column approval from a spot check of data rows. Its own wording explains why: if a column meaning is wrong, every row in it is wrong. Adopt that order of review. Confirm headers and types first, then sample several rows from each important variant or price tier.<\/p>\n Where a workbook has several sheets, make their relationship explicit. A visitor cannot know that an eligibility rule is on a different sheet from the base price. Bring the condition into the approved customer-facing table, or keep that question with a person.<\/p>\n A direct question such as \u201cWhat does the Pro plan cost?\u201d is too easy. Use questions that force the expected conditions into view. For a fictional lab-supplies sheet, test \u201cWhat is the price per box of sterile gloves in Germany for an annual order?\u201d If price, pack size, country and term are separate columns, the answer should preserve all four. If the table cannot support the combination, route the question to sales instead of inferring an offer.<\/p>\n Also test negative cases: \u201cCan I get the wholesale rate for one unit?\u201d and \u201cWhat will the price be next year?\u201d An approved list may not support either claim. A refusal is preferable to a fabricated calculation or a promise based on a stale effective date.<\/p>\n Pricing and variant data change frequently. Establish a basic handoff: the owner exports a reviewed file, an editor confirms the sheet and headers, the old source is paused or removed from use, and the affected questions are re-tested. Retain the version name and effective date so a later conversation can be interpreted correctly.<\/p>\n Do not rely on cell colour, comments or a colleague\u2019s memory to express an exception. Put it in readable text beside the value. Decide what blank values mean\u2014unavailable, not applicable, pending confirmation or error\u2014before testing visitor questions.<\/p>\n RobiFox says website changes are re-read weekly, but that is not a claim of live spreadsheet sync. Document uploads need their own change process. The platform\u2019s review queue is designed to show conflicts and keep human edits from being overwritten; use that control to resolve discrepancies rather than retaining two competing price lists.<\/p>\n Check that each tested answer cites the source, includes the conditions that determine the cell value, and declines account-specific discounts or unapproved exceptions. Keep a small regression set for high-value rows. If a visitor reports an incorrect price, inspect the cited source, table header, row and effective version before changing the answer.<\/p>\n RobiFox\u2019s documented answer tests allow teams to record visitor-style questions, expected sources and questions that must stop. That makes them a useful final check around spreadsheet content. See How it works<\/a>, source features<\/a> and How we measure<\/a>.<\/p>\n For the next step, check document versions and PDF structure<\/a>.<\/p>\n Cover image: AI-generated editorial illustration, not a product screenshot.<\/small><\/p>\n The free website preview<\/a> covers up to 10 website pages with email confirmation; it does not demonstrate your Excel workbook. Use the setup guide<\/a> for supported document upload and test the actual questions against your approved table.<\/p>\n\n
\n \nField<\/th>\n Why visitors need it<\/th>\n<\/tr>\n<\/thead>\n \n Product or service variant<\/td>\n Prevents a price for one configuration being quoted for another.<\/td>\n<\/tr>\n \n Unit and currency<\/td>\n Stops \u201cper month,\u201d \u201cper pack\u201d and tax status from disappearing.<\/td>\n<\/tr>\n \n Market and region<\/td>\n Separates offers or delivery rules that do not apply everywhere.<\/td>\n<\/tr>\n \n Conditions<\/td>\n Makes thresholds, term lengths and exclusions discoverable.<\/td>\n<\/tr>\n \n Effective date and owner<\/td>\n Gives the team a route to replace obsolete data.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n Test questions that combine columns<\/h2>\n
Manage revisions as source changes<\/h2>\n
Verify answers with visitor evidence<\/h2>\n
Try a document through the supported setup<\/h2>\n