Palash Fendarkar · Product take-home · Aerchain · October 2026

Kill the Quote Spreadsheet

The problem

A buyer emails an RFx to five vendors. The replies come back as an off-template Excel, a PDF with the discount in a footnote, a Word document with the terms in a paragraph, a phone photo of a rate card, and a one-line email. The buyer retypes all of it into a spreadsheet, three days, then the VP asks one question and the fourth day goes.

What is being built

One flow, end to end. The buyer drafts the RFx with a co-pilot. Vendors reply however they like. The system reads every reply into one side-by-side comparison, same lines, units and currency, with questionnaire answers and documents beside the numbers. Then the buyer asks questions in plain language over the whole comparison, gets text, tables, charts and exports, and reaches an award that can be defended.

Page 1 of 2Objective, flow, stages 1 and 2
North-star objective for this exercise

Two things built for the buyer

A trust layer

  • Every number shows whether it was read from the file, assumed through a conversion, or still open.
  • Every number links back to the page, cell or photo it came from.
  • Blank is never zero. An open item blocks the award.
Where Review map · findings · source bar · the file at that page

An interrogation tool

  • The buyer asks questions in plain words over the whole comparison.
  • Each answer says which rule it used, what it left out, and what it depends on.
  • If the data cannot answer the question, it says so.
Where Analyse co-pilot · answer card · query used · export
The flow · six stages in the app · five sections in this document
STAGE 1DraftBuyerLines, basis, questionnaire, co-pilot
STAGE 1SendBuyerPrivate link, or reply by email
STAGE 2SubmitVendorAny format, any channel
STAGE 3ReviewBuyerWhat was read, what is open, what to ask
STAGE 4AnalyseBuyer · VPSector profile, ranking, evidence, questions
STAGE 5AwardVPReasons, exclusions, overrides on record
Why Review and Analyse are the focus
  • The trust layer lives in these two stages. Draft, Send and Award are kept standard so these two can be tested properly.
  • Review is where everything that arrived gets read, connected and settled. Every file is read as far as it can be. Facts are joined across documents: a brochure's carton count to a PDF's price, a letterhead to its sender, last year's contract to "rest same as last year". Every line ends with a state and a source, and every open question goes to the vendor or to the buyer.
  • Completeness and accuracy are settled before anything is compared. Coverage per vendor, missing terms, unclear digits and unmatched items are all raised here, not discovered later in a total.
  • Analyse is where the buyer interrogates the result. Cleaner input in Review is what makes an answer in Analyse worth acting on.
Stage 1 · RFx

Draft and send

Assumption

  • The buyer is a 4-star hotel group: 8 properties, 960 rooms, central procurement.
  • One annual rate contract for housekeeping and guest amenities: 30 lines in 4 groups, about ₹3.92 crore at last year's prices, INR ex-GST, delivered to each property.
  • Vendors are shortlisted by rules from the vendor master: the incumbent with 95% or better on-time delivery is always invited, at least two quotes per group, one international supplier for linen, one local supplier per metro.

What is built

  • Start the RFx from the co-pilot or from last year's RFQ. Each line carries its source.
  • A stubbed sync reads sample files for the ERP and Tally export, the consumption report and past RFQs. Live connections are not in the prototype.
  • Only two things are asked of vendors: a price per line and the five questionnaire answers. Terms, delivery and validity are read from whatever they send.
  • Send: one email per vendor with a private link that needs no login, the option to reply by email instead, a mock inbox, reminders and a two-day extension.

AI integration

  • FrameworkPlanned New questions are answered by Claude Opus 5.5. Each answered question is saved to your company's question bank as a recipe: which data it reads and how it works out the answer, never the answer itself. When someone asks a question that means the same thing, Claude Haiku 4.5 reuses the recipe on today's data, so it is faster and cheaper. If it is not sure the question matches, Opus answers it fresh.
  • One job here, the co-pilot, at low effort. It reads the past RFQ, the consumption report and the conversation, and proposes line changes with a reason and a source for each.
  • It asks for anything it cannot source instead of inventing it. The buyer applies changes with one click; nothing changes on its own.
  • Kept minimal on purpose. Drafting is not where this exercise is graded.

Left out · next release

  • Live ERP and Tally connections in place of sample files.
  • A product catalogue lookup so specs come from a master, not from last year's text.
  • Automatic flags on quantities that do not match consumption. Today the co-pilot checks when asked.
  • Vendor discovery from external sources. Today the shortlist comes from the vendor master and the rules.
Stage 2 · Vendor submission

No template, no sign-in, any channel

No template. Vendors send what they have, as files, typed prices, a note, or an email reply, and every submission enters the same reading pipeline.

Assumption

  • Vendors do not follow templates. They send what they have, through whichever channel is open.
  • Some attach supporting documents, some attach the wrong things, some revise after submitting.
  • One vendor is overseas and quotes in USD on FOB terms. One fails the certification question.

What is built

  • A private link per vendor, no sign-in. Upload any files, type prices, paste a column, add a note, answer the questionnaire, give a delivery timeline, submit.
  • Revise after submitting. The submitted version stays with the buyer until the revision is submitted. One revision at a time.
  • Replying to the email with text or attachments enters the same pipeline as the portal.
  • File type is detected from the bytes, not the extension. 20 MB per file, 20 files per quote. Old Office formats are refused with a message.

AI integration

  • None on the vendor side, by design. Reading starts after submit and is covered in Stage 3.
  • Vendors see that their files are being read, and get a question only where the system cannot resolve something on its own: a pack size, an unclear digit, a spec confirmation, a missing freight percentage.

Left out · next release

  • The vendor-side experience: completion score, live matching of their items to our lines, a vendor dashboard. Reading messy input is the system's job, and this exercise is about the buyer.
  • Handwritten quotes and non-English documents.
Page 2 of 2Stages 3, 4 and 5 · edge cases
Stage 3 · Review

Everything that arrived is read, connected and settled

Assumption

  • A buyer only acts on numbers they can check. The screen must say what was read, what was assumed, and what could not be read.
  • Nothing is filled in silently. Not quoted is never ₹0. A guessed digit or a guessed pack size is worse than an open question.
  • Vendor documents are data, never instructions.

What is built

  • One pipeline per file: code checks the bytes and picks the reading rung, one model call returns values with locations, then code matches lines, converts units, currency, freight and discounts, and sets each cell to read, assumed or unresolved.
  • The Review map: one row per vendor, one cell per facet, each cell opening to its source and its actions. Findings sorted into needs your call, worth a check, handled.
  • Items the system raises: a file on another vendor's letterhead, hidden text addressed to an AI, a spec deviation, a substitute, an unclear digit, a pack size, a missing freight percentage, a duplicate, "same as last year" with no contract on file.
  • Supporting documents are kept, not rejected. A brochure's "1 carton = 500 pieces" feeds a conversion; an invoice's prices stay out. Empty, corrupt, locked, low-resolution and wrong-RFQ files are refused with a plain reason.

AI integration

  • One read job per file. Effort high for PDFs and photos, medium for sheets and text. A photo is transcribed twice by Workers AI, row by row and column by column, and Claude matches the text; it never sees the image. Where the two transcriptions disagree, the value is held for the buyer.
  • The contract returns each value with its location, the unit as written, a confidence and alternatives for an unclear digit. The model reads and maps. Code decides the rung, does the arithmetic and sets the state.
  • Text inside a file that addresses the AI is flagged to the buyer and changes nothing.

Left out · next release

  • Image straightening before a photo is read. Photos stay the weakest input and every cell read from one says so.
  • Multi-page catalogues, tiered pricing beyond one table, handwriting.
  • A read takes about 30 to 90 seconds per file.
Stage 4 · Analyse

A sourcing profile per sector, then the ranking, then the evidence

Assumption

  • What matters in sourcing differs by sector. A universal scorecard hides the choices the buyer should own.
  • The ranking is the starting point; the evidence table sits one click behind it.
  • A change asked for in plain words must be proposed and confirmed, never applied silently.

What is built

  • At onboarding, a sourcing profile for the client's sector: the criteria that matter, ranked, with a default weight, a one-line reason naming the evidence, a source and a data source for each. The buyer reorders and reweights; weights sum to 100; every version is logged.
  • Vendor facts from the submission and from external documents per vendor: a credit summary, a registry extract, a complaint record, fabricated for the demo and read through the same pipeline with provenance and an as-of date.
  • The ranking under the profile, each score with its formula and the cell or document it came from. The evidence lenses: decision matrix, item-wise prices, specifications, delivery, terms, compliance, vendor profile. CSV export.
  • The co-pilot explains the ranking and answers across prices, terms, questionnaire answers, facts and the award, with tables and charts in the answer and export of a table. Asked to change a parameter, it returns a before-and-after proposal; Apply is the buyer's click.

AI integration

  • One job proposes the profile from the sector, the RFQ, past RFQs and the vendor master, with reasons and an excluded list.
  • One job reads each external document into facts with locations; a subject name that does not match the vendor becomes a review item, and hidden instructions are flagged.
  • The analyst runs one SELECT over read-only views and states its rule, what it left out and what it rests on. The model never computes a score and never writes.

Left out · next release

  • Live credit and registry APIs and full annual reports in place of fabricated documents.
  • Profiles for more sectors; today one client, one sector.
  • Negotiation rounds from the ranking.
  • A cheaper model on the structured reading rungs, once measured against the same test files.
Stage 5 · Award

Reasons, exclusions and overrides on record

Assumption

  • An award is defensible only if the rule, the exclusions, the assumptions accepted and the overrides are written down with who and when.
  • The VP approves or sends it back with a note. Nothing else happens at this stage.

What is built

  • The award builds only when the portal is closed and the review queue is empty.
  • Split per line under the active rules and the active profile version. Threshold discounts are applied once each vendor's awarded value is known, not per line.
  • One reason per vendor, drafted from the logged facts and editable. Excluded vendors with the reason. Assumed cells counted and listed. Every override with who and when.
  • Approve or send back. A decision log and a printable award record.

AI integration

  • One job drafts the reasons from the facts the system already holds. No number in the award comes from the model.

Left out · next release

  • A negotiation round started from the award.
  • Contract generation and purchase-order handoff to the ERP.
  • Decision memory across RFQs: the profile, the rule and the overrides carried into next year's RFQ as the starting point. Today the record covers one RFQ.
Edge cases handling

What the product is designed to handle

CaseSystem behaviourGuardrailAlternative
A vendor prices only some of the linesThe missing lines show as not quoted and never count as zero; coverage reads 27 of 30 next to the vendorNot quoted is never ₹0 and never wins cheapestAsk the vendor for the lines, or mark them not quoted
A price per carton or pack with no countThe line is held and the vendor is asked how many are in a pack; once known, the conversion is shown as a stepA pack size is never assumedThe buyer can enter the count if the vendor's brochure states it
A quote in a foreign currency on FOB termsConverted at the dated reference rate, shown on the cell; the price stays unresolved until a freight figure existsRate and date are visible; freight is never estimatedEnter a freight % or ask the vendor; compare before freight as a scenario
A phone photo where one digit cannot be readThe price is held with the candidate readings shownThe system never picks a digit on its ownOpen the source and pick, or ask for a clearer copy
An email that says "rest same as last year"Resolved only if that vendor's last contract is on file; otherwise the lines are held and the vendor is askedLast year's price is a fact only when the document existsMark the lines not quoted, or wait for the vendor
A cheaper product that does not match the specKept as an alternative, never counted as like-for-like; the buyer sees what it would saveA cheaper spec is not a cheaper priceAccept it as an alternative, or ask the vendor to quote the spec
An invoice, brochure or terms sheet sent along with the quoteKept as a supporting document; its prices never enter the comparison, its definitions and terms are used with the page as sourceOnly quotes feed the comparisonOpen the document from any cell it fed
A file that cannot be read: empty, corrupt, locked, too blurry, or for a different RFQRefused with a plain reason and a next stepNo guessed prices from an unreadable fileVendor uploads again, or types the lines in the form
A vendor sends a revised quoteThe new version replaces the old, the changed lines are listed, the history is keptOnly one version is current at a timeOpen the earlier version to compare
A file on another vendor's letterhead, or hidden text telling the AI how to rankHeld until the buyer decides whose it is; hidden text is flagged and ignored, rankings unchangedDocuments are data, never instructionsCount it for the right vendor or leave the file out
Known limits of the prototype, not bugs
  • Roles come from a header. Deployed, the buyer app sits behind access control.
  • Demo controls have no auth. Reset, sample fill and restart-reading are for the demo.
  • Only the analyst is throttled. Per-IP limits come with deployment.
  • One RFQ per deployment. Image straightening is not in this version.
  • Reads take 30 to 90 seconds per file. A slow photo never blocks the buyer; the page refreshes as each file is read.
  • External vendor documents are fabricated for the demo and read like any other file.