build.allanninal.dev

Part 2 of 7 · Vendor onboarder series ~4 min read

How a vendor gets invited

The onboarder can only chase a vendor it knows about. So the first job is starting the vendor — creating its folder, its checklist, and sending the supplier a link where they can upload. There are three ways a vendor gets started: an owner fills a short form, a salesperson forwards the supplier’s first email, or somebody adds a row in the Drive sheet. The first one is the clean path. The other two exist because in real life people don’t open a form for a supplier they just agreed to use over the phone.

Key takeaways

  • Three intake lanes start one vendor file: a web form, an inbox-forwarding lane, and a Drive sheet row.
  • The forwarded-email lane uses Bedrock Haiku 4.5 to read the supplier’s name and contact from the message.
  • Every started vendor gets a folder in S3, a checklist row in DynamoDB, and a private upload link.
  • The vendor type (contractor, software, supplier) decides which documents the checklist asks for.
  • The upload link is a Lambda Function URL — a small page, not a heavy web app.

Three lanes into one vendor file

Three intake lanes start one vendor file A diagram with three vertical lane columns at the top and a single unified row at the bottom. Lane one, Web form: an owner opens a short page served by a Lambda Function URL and types the vendor name, contact email, and vendor type; on submit, the intake Lambda creates the vendor file. Lane two, Inbox forwarding: a salesperson forwards the supplier's first email to a dedicated address; SES writes the raw message to S3; an intake Lambda calls Bedrock Haiku 4.5 to read the supplier's name and contact off the message and proposes a vendor; the owner confirms the vendor type in a one-tap message before the file is created. Lane three, Drive sheet: somebody types a row into a Google Sheet with vendor name, contact, and type; a sync Lambda picks up the new row hourly and starts the vendor the same way. All three lanes converge on the same action: create a folder in S3 for the documents, a checklist row in DynamoDB seeded from the checklist doc for that vendor type, and send the supplier a private upload link by email. A note at the bottom: whichever lane starts a vendor, the result is identical — one folder, one checklist, one upload link. Lane 1 · owner Web form • Owner opens the Function URL page • Types name, email, vendor type • Submit starts the vendor at once • The clean path when you have time Lane 2 · SES + Haiku Inbox forwarding • Forward supplier email to address • SES writes it to S3 • Haiku reads name and contact • Confirm type, then start vendor Lane 3 · hourly poll Drive sheet • Type a row: name, contact, vendor type • drive-sync polls the sheet hourly • New rows start a vendor each • Good for adding several at once Start the vendor (same for every lane) S3 folder · DynamoDB checklist row · seeded from checklist doc by type · upload link the supplier gets a private link to upload — one item at a time to document checker Whichever lane starts a vendor, the result is identical — one folder, one checklist, one upload link.
Fig 2. Three lanes converge on one action: start the vendor. Whether it came from the form, a forwarded email, or a sheet row, the onboarder creates the folder, seeds the checklist for that vendor type, and sends the supplier a private upload link.

Lane 1: the web form

The simplest lane. The owner opens a small page — a Lambda Function URL, so it’s a single function serving one form, not a hosted web app — and types three things: the vendor’s name, the contact email, and the vendor type (contractor, software supplier, goods supplier, and so on). On submit, the intake Lambda creates a folder in S3 for the vendor’s documents, writes a checklist row in DynamoDB seeded from the checklist doc for that type, and emails the supplier their private upload link.

The vendor type is the only field that changes what happens next. A contractor’s checklist asks for bank details, a tax form, and an insurance certificate. A software supplier’s might ask only for bank details and a tax form. The checklist doc holds those lists in plain prose, so adding a new type is an edit, not a deploy.

Lane 2: inbox forwarding (the lane most teams actually use)

Set up a dedicated inbound address — something like vendors@your-company.com — via Amazon SES. When a salesperson agrees a deal over email and the supplier replies with their details, the salesperson just forwards that email to the address. SES writes the raw message to s3://vo-raw-mime/. The S3 write triggers the intake Lambda, which calls Bedrock Haiku 4.5 to read the supplier’s company name and the best contact email out of the message.

The model prompt is short: “Read this email. Return JSON with the supplier company name and the contact email. Do not invent details that aren’t there.” The result goes to a small message to the owner with the proposed vendor and a one-tap choice of vendor type. Only on that confirmation is the vendor file created. The reason a human picks the type is that the type decides the whole checklist, and guessing it wrong means asking the supplier for the wrong documents.

Lane 3: the Drive sheet

Some teams prefer to line up several vendors at once — after a trade show, or when switching suppliers across a category. For them, the registry is a Google Sheet with one row per vendor: name, contact email, vendor type. A small drive-sync Lambda runs hourly, reads the sheet via the Sheets API, and starts a vendor for any new row it hasn’t seen before. The same create-folder, seed-checklist, send-link steps run for each one.

The sheet doubles as the owner-facing view later: the same drive-sync Lambda writes each vendor’s checklist status back into the sheet, so a manager who lives in spreadsheets can see at a glance which vendors are still collecting and which are ready to approve.

What the vendor sees

The supplier gets one email: a short, friendly note in your voice that says what you need and why, and a button that opens their private upload page. The page is theirs alone — the link carries a long random token, so nobody can guess another vendor’s page — and it lists each required document with a place to drop a file. They can upload one item now and the rest later; the page remembers what’s already in. There’s no account to create and no password to set, which is exactly what a busy supplier wants.

Funneling all three lanes into one start action means there is exactly one vendor file per supplier, no matter how it began. The next post follows a single uploaded document through the checker: how it gets read, how the system decides present-or-missing and in-date-or-expired, and why a human confirms before any item counts as done.

All posts