Vendor Applications

How Applications Work

A vendor is somebody else selling through your shop. Applications are how they ask, and how you decide.

Where to find it

Architect Panel → Commercial:

• Carts — the cart itself and its options
• Shop Insights — what buyers looked for
• Vendor Approvals — applications waiting on a decision

Architect Panel → Data:

• Datastores — then View Data on a cart table, where most shop administration lives

You design the form

The application form is not fixed. Each field is defined with a name, a type, a description, validation, whether it is required, its position, and whether the value is encrypted.

So you ask for what your business actually needs to decide — company number, VAT registration, insurance, bank details, product categories — rather than a generic set.

Encrypt the sensitive fields

Applications collect bank details and identity documents from people who are not yet your vendors and may never be. Anything of that kind should be marked encrypted, and the retention of declined applications should be deliberate rather than forever.

Ask only what decides the outcome

Every field is a reason for a genuine applicant to give up, and a piece of personal data you now hold. If a field would not change your decision, leave it out and ask later.

What approving means

More than adding a record. An approved vendor can list products on your shop, and your customers will experience their products, their descriptions and their fulfilment as part of your business.

So the decision is commercial rather than administrative, and the person making it should be somebody who can make that judgement.

Vendors get their own pages

A vendor has a name, logo and description, and can have store pages of its own. Whether you offer that is a positioning decision — it makes the marketplace visible, which some businesses want and others do not.

Products can require approval

Separately from the vendor. Approving a vendor need not mean approving everything they subsequently list, and for most marketplaces it should not.

Decide the response time and meet it

Applications go stale. A vendor waiting three weeks has usually gone elsewhere, and the application sitting in a queue is personal data you are holding for nothing.

Worked example

A marketplace asks for company number, VAT number, product categories, public liability insurance and bank details, with the last two encrypted. Applications are reviewed within five working days by the category manager. Approved vendors get a store page; every product they list still needs approval.

Recommendations

• Ask only what decides the outcome.
• Encrypt bank and identity fields.
• Approve products separately from vendors.
• Set a response time and hold to it.

Reviewing Applications

Applications arrive with a status and wait for a decision.

Where to find it

Architect Panel → Commercial:

• Carts — the cart itself and its options
• Shop Insights — what buyers looked for
• Vendor Approvals — applications waiting on a decision

Architect Panel → Data:

• Datastores — then View Data on a cart table, where most shop administration lives

The actions

An application can be approved, declined, or revoked after the fact — and an earlier decision can be changed to approved. That last one matters: a vendor declined for a missing document should be approvable once it arrives, without reapplying.

Approval notes are recorded against the application, which is where the reasoning belongs.

Write the reason down

Every time, approval as well as decline. Six months later somebody will ask why a vendor was accepted, and "it seemed fine" is not an answer that survives a complaint or an audit.

What to check

• Do they exist — company number against the register.
• Are the documents current — insurance certificates expire.
• Do the products fit your shop and your customers.
• Can they fulfil — your customers will blame you, not them.
• Is anything restricted — some product categories carry obligations you would be taking on.

One person should not decide alone

For anything material. Vendor approval is a commercial decision with a fraud dimension, and a single approver is a single point of failure in both directions.

Revocation needs a process too

A vendor who stops fulfilling, or whose insurance lapses, has to be stoppable quickly. Know who can revoke and what happens to their listed products when it happens — an unanswered question until the day it is urgent.

Expiring documents need re-checking

An insurance certificate valid at approval is not valid forever. Either record the expiry and review it, or accept that your vendor checks are a snapshot of the day they applied.

Handle the queue on a schedule

A fixed day each week beats good intentions. Applications that sit are the ones that get decided badly, in a hurry, by whoever happened to notice.

Worked example

Applications are reviewed each Tuesday against a five-point checklist, with the reasoning noted whichever way it goes. Anything above a value threshold needs a second approver. Insurance expiry dates are recorded and reviewed quarterly, which caught two vendors trading on lapsed cover.

Recommendations

• Note the reasoning for approvals as well as declines.
• Use a written checklist.
• Two approvers for anything material.
• Record document expiry and review it.

Declining Well

Most applications are declined. How you do it affects your reputation among exactly the businesses you want to attract later.

Where to find it

Architect Panel → Commercial:

• Carts — the cart itself and its options
• Shop Insights — what buyers looked for
• Vendor Approvals — applications waiting on a decision

Architect Panel → Data:

• Datastores — then View Data on a cart table, where most shop administration lives

Architect Panel → Layout & Pages:

• E-mail Templates — the message itself

Be clear that it is a decision

The worst decline is an ambiguous one. If the answer is no, the message should say no — not "we are unable to progress at this time", which people read as "try again next week" and then do, repeatedly.

Distinguish "no" from "not yet"

Two genuinely different outcomes deserving different messages:

• Not yet — something is missing or expired. Say what, and say they may reapply. The platform supports changing that decision to approved later without a fresh application.
• No — they do not fit, or you found something. Be polite, be brief, and do not invite a reapplication you will decline again.

How much reason to give

Enough to be fair, not so much that you are negotiating. For a missing document, say exactly what is missing. For a commercial fit decision, "we are not taking on vendors in this category" is honest and closes the matter.

For anything you found in a check, say less rather than more — and take advice before writing anything that alleges something.

Keep it short

A decline should be three or four sentences. Long ones read as defensive and invite line-by-line rebuttal.

Say what happens to their data

They gave you bank details and documents. Telling them what you will now do with those is both good practice and something you are likely obliged to do.

Which means having decided — a declined application retained indefinitely is a data-protection question waiting to be asked.

Give a route to a person

One address, monitored. Declines generate replies, and an unanswered reply to a decline is how a routine no becomes a complaint.

Send it promptly

The same day the decision is made. A decline three weeks after applying is worse than the decline itself.

Worked example

A marketplace uses two templates: one saying which document is missing and inviting the applicant to send it, and one declining on category fit. Both are four sentences, both say declined applications are deleted after ninety days, and both give a monitored address. The first recovers roughly a third of applicants.

Recommendations

• Say no clearly when it is no.
• Separate "not yet" from "no" with different messages.
• Four sentences is enough.
• State what happens to their data, having decided.