An operator with 140 vendors across thirty properties rolls out a portal in March. By September, 56 vendors have logged in at least once, which the dashboard reports as 40% adoption. The other 84 are still emailing PDF invoices to the property accountant, who re-keys them, and phoning the coordinator to ask whether the work order is approved. The portal was mandated in a letter to every vendor. The mandate is being ignored, and the accountant is doing the same work as before plus the work of chasing people to use the portal.
Here is the half of the story the operator did not write. A plumber with four vans and an office manager who does the books on Thursday evenings received the letter, logged in once, could not find the work order she had been sent by phone that morning, was asked to upload a certificate of insurance she had already emailed twice, and could not see when the last three invoices would be paid. She went back to email. Nothing about the portal paid her faster or asked her to type less, so from where she sat it was a new chore imposed by a customer that represents 8% of her revenue.
The vendor portal property management operators actually get adopted is a deal, not a mandate. The vendor gives up its own invoice format, its habit of phoning, and a little control over how work is confirmed. In return it has to get something: faster payment, less re-keying, clearer scopes, and visibility of where its money is. This post sets out the four things a portal has to do, what vendors expect from it (from their chair, not the operator's), what the operator needs from it, why adoption fails and how to fix each failure, a rollout that starts with ten vendors, and what to have in place before mandating anything.
Definition
A vendor portal in property management is the vendor-facing channel through which contractors and service providers receive work orders and purchase orders, accept or decline them, confirm attendance and completion with evidence, submit invoices against the work order, and see the status of approval and payment. RIOO's rule is that a portal is a deal, not a mandate: vendors adopt it when it pays them faster and asks them to type less, and mandates without that exchange stall well short of full adoption. The portal is the vendor's side of stage 5 (dispatch) and stage 6 (pay) in RIOO's eight-stage vendor lifecycle.
At a glance
| Question | Answer |
|---|---|
| What must a vendor portal do? | Four things: deliver work, confirm completion with evidence, take the invoice against the work order, and show payment status |
| What do vendors expect from it? | Faster and more predictable payment, no re-keying, clear scopes and approvals, a mobile experience for the technician, one place to keep their documents current, and to see where their money is |
| Why does adoption stall? | The portal adds work for the vendor without paying them back; work orders still arrive by phone; invoices are rejected for reasons the vendor cannot see; the technician has no mobile access; the office manager was never trained |
| What does 40% adoption cost? | In the example, 228 emailed invoices a month re-keyed at 12 minutes each is 45.6 hours of accountant time, plus the chasing |
| How should it be rolled out? | Pilot with ten willing high-volume vendors, fix what they find, publish the payment promise, then extend by trade with a date after which email invoices are returned |
| What must be in place before mandating? | A payment-terms commitment the operator will keep, work orders that only issue through the portal, a mobile path for technicians, document reminders instead of demands, and someone who answers vendor questions inside a day |
The four things a portal must do
Vendor portals (also sold as a contractor portal, a work order portal or a vendor self-service module) are marketed on feature lists. From the vendor's side they have four jobs, and a portal that does the four well with nothing else will be adopted over one that does twenty things badly.
-
Deliver the work: The work order or purchase order arrives in the portal with the scope, the priority, the property and unit, the access instructions, the site contact, the agreed rate or the PO amount, and the deadline. The vendor accepts or declines it there, which starts the SLA's acknowledge clock (see the vendor SLA template). If work also arrives by phone, text and email, the portal is one channel among four and will lose.
-
Confirm completion with evidence: The technician marks arrival, marks completion, attaches photos and a note, and, where the property requires it, gets the site contact's sign-off. That record is the evidence the SLA clocks are measured against and the evidence the invoice is paid against. It has to work on a phone, on site, in a basement with poor signal, or it will be done from memory in the van afterwards.
-
Take the invoice against the work order: Vendor invoice submission happens from the completed work order, so the PO number, the property, the amount and the scope are already on it. The portal checks it against the PO or the rate card and tells the vendor immediately if something does not match, rather than the invoice disappearing into a queue and being rejected three weeks later for a missing PO number.
-
Show payment status: The vendor sees the invoice move: received, matched, approved, scheduled, paid, with a date. This is the job operators most often leave out and the one vendors value most, because it replaces the Thursday-evening phone call to accounts payable with a glance.
What a plumber sees on Tuesday morning
It helps to walk through the portal from the other chair.
7:40 am. The office manager opens the portal on her laptop with coffee. Overnight, two work orders arrived from the operator: a P2 water heater at Building C, unit 214, with a photo of the leak, the resident's availability window, the gate code, and the agreed rate card attached; and a P3 slow drain at Building A, common laundry. She accepts both. The acknowledge clock stops on each.
8:05 am. She assigns the water heater to Danny, who sees it on his phone with the address, the unit, the gate code and the photo. No phone call to the coordinator, no "which building was that again".
10:30 am. Danny arrives, taps arrived. Attend clock stops. The heater needs replacing rather than repairing; he photographs the corroded tank and the serial plate, and submits a change request from the work order with the replacement cost from the rate card. The coordinator approves it from her phone in eleven minutes. Danny proceeds.
1:15 pm. Danny taps complete, attaches three photos and the model of the new heater, and the resident signs on his screen. Restore clock stops.
1:20 pm. The office manager sees the completed work order, taps invoice, checks the pre-filled amount against the approved change request, and submits. The portal confirms the PO matches. Status: received.
Thursday. She checks the portal instead of phoning. The water heater invoice shows approved, scheduled for payment on the 24th. Last month's three invoices show paid. She also sees a banner: the general liability certificate expires in 30 days, with an upload button. She uploads the renewal her broker sent yesterday.
Every step in that morning either saved the plumber time or told her something she used to have to ask for. That is what adoption looks like. Take away the pre-filled invoice, the payment date, the mobile app for Danny or the certificate reminder, and each removal is a reason to go back to email.
What vendors expect
The expectations below come from the vendor's side of the relationship and are the standard a portal is measured against by the people who have to use it.
| Vendors expect | What it means in practice | What happens without it |
|---|---|---|
| To be paid faster, and to know when | Portal-submitted invoices paid on shorter terms than emailed ones (net 15 or 20 against net 30 or 45), and a visible scheduled payment date | The portal is extra work with no return; the vendor keeps emailing and phoning |
| No re-keying | The invoice is generated from the completed work order with PO, property, scope and amount pre-filled; the vendor adds a line or a document, not a whole form | The office manager types the same invoice twice, once in her own system and once in the portal |
| Clear scope and approval before the work | Every work order carries the scope, the rate or PO amount, the priority and the access details; changes are requested and approved in the portal before the extra work is done | Disputed invoices after the fact; the vendor eats the cost or the property pays for unauthorised work |
| A mobile path for the technician | The person on site can accept, check in, photograph and complete from a phone, offline if needed | The technician does the paperwork from memory in the van; the evidence is thin and late |
| One place for their documents, with reminders | Insurance, licence and W-9 held once, with an expiry reminder and an upload button, rather than repeated email demands | The vendor sends the same certificate to four properties and is still asked for it |
| To see where their money is | Invoice status from received to paid, with dates, and a history | Weekly phone calls to accounts payable; the vendor's own cash-flow planning is guesswork |
| Immediate rejection reasons | A mismatched PO, a missing photo or a wrong rate is flagged at submission, not weeks later | Invoices vanish into a queue and come back rejected after the vendor has already chased payment |
| A human who answers | A named contact who resolves portal questions within a day, at least during rollout | The first unanswered question is the last login |
| Proportionality | A per-job handyman is not asked for the same set-up as a contracted elevator company | Small vendors, who are often the responsive ones, opt out |
Two of these are worth underlining because they are the ones operators most resist. The first is faster payment for portal invoices. Operators see it as giving something away; it is the price of the deal, and it costs less than the accountant hours the re-keying consumes. The second is immediate rejection reasons. Operators worry about exposing their matching rules; vendors experience a silent rejection as the portal losing their invoice.
What the operator needs
The operator's requirements are the other side of the same record, and they are what make the portal worth running.
Insurance and compliance gating: a vendor whose certificate has lapsed cannot accept a new work order until the renewal is uploaded, which turns the COI tracking process from chasing into a gate. PO and rate-card matching: the invoice is checked against the approved amount before it reaches an approver, and the change-request step means unapproved extras cannot appear on it. Evidence on every completion: photos, notes, sign-off and timestamps, which are the SLA record and the dispute record. A single channel: work orders that issue only through the portal, so that the acknowledge, attend and restore clocks have one start event and one set of evidence. Vendor self-service on documents: the vendor keeps its own record current, prompted by reminders, rather than the compliance team collecting. And the data: response times, completion times, first-time-fix, invoice accuracy and rejection rates by vendor, which feed the scorecard without anyone compiling a spreadsheet.
Related reading: Vendor Performance Review Cadence: Weekly, Monthly, Quarterly, Annual
The operator's needs and the vendor's expectations are not in conflict; they are the same record seen from two ends. The operator gets gating, matching and evidence exactly when the vendor gets clarity, speed and visibility. Where the portal is designed only from the operator's end, the vendor's half is missing and adoption shows it.
Why adoption fails, and the fix for each
| Failure mode | What it looks like | Fix |
|---|---|---|
| Portal is extra work with no return | Vendors are asked to submit invoices in the portal and are paid on the same terms as before | Publish and keep a payment promise: portal invoices paid on net 15 or 20; emailed invoices on net 45 (or, after the cut-over date, returned) |
| Work still arrives by phone | Coordinators call the vendor and "put it in the portal later"; the vendor learns the portal is optional | Work orders issue only through the portal; P1 calls are followed by a portal work order within the hour, and the vendor is asked to accept it there |
| Re-keying | The invoice form asks for everything from scratch | Invoice from the completed work order with PO, scope and amount pre-filled; allow a PDF attachment for the vendor's own invoice copy |
| Silent rejections | Invoices sit in a queue and come back weeks later with "no PO" | Validate at submission and show the reason; an invoice that cannot be matched is not accepted, and the vendor is told why on the spot |
| No mobile path | The office manager can use it; the technician cannot | A mobile app or mobile web for accept, check-in, photos, complete; offline capture that syncs |
| Document demands, not reminders | Vendors receive emails asking for certificates they have already sent | Documents held once on the vendor record with expiry reminders and an upload button; the compliance team stops emailing |
| Nobody trained the office manager | The letter said "log in"; the person who does the books never saw a demonstration | A 20-minute onboarding call per vendor during rollout, with the first invoice submitted together |
| One size for all vendors | The elevator company and the handyman get the same 14-step set-up | Tiered set-up: per-job vendors need identity, insurance, bank and a work order; contracted vendors add the SLA and PO flow |
| No owner on the operator side | Vendor questions go to a shared inbox and wait | A named portal owner during rollout who answers inside a day and fixes recurring problems in the configuration |
| Measuring logins instead of behaviour | "40% adoption" counts vendors who logged in once | Measure the share of invoices submitted through the portal and the share of work orders accepted there; report by vendor and by trade |
The last row is the one that changes the conversation. Logins are not adoption. The number that matters is the share of invoices that arrive through the portal, because that is the number that converts directly into accountant hours and payment accuracy.
What the 40% costs. In the opening example, the operator receives about 380 vendor invoices a month. With 60% still arriving by email, that is 228 invoices re-keyed at, say, twelve minutes each: 45.6 hours of accountant time every month, plus the calls, plus the matching errors that re-keying introduces. At full portal adoption that time goes to zero and the invoice arrives already matched to the work order. The payment-terms concession that buys adoption is cheaper than the hours it saves.
The rollout: start with ten vendors
Portals fail when they are launched to everyone at once by letter. They succeed when they are introduced as a working deal to a small group who will tell you what is wrong, and then extended trade by trade with the fixes applied.
| Step | What to do | How long |
|---|---|---|
| 1. Pick the pilot ten | High-volume, cooperative vendors across four or five trades, including at least two small ones with an office manager rather than a back office | Week 1 |
| 2. Agree the deal | Tell them what they get: portal invoices paid on the shorter terms, pre-filled invoices, a payment-status view, one place for documents. Tell them what you need: accept work in the portal, evidence on completion, invoice from the work order | Week 1 |
| 3. Onboard by hand | A 20-minute call with each vendor's office manager; set up their users; submit the first invoice together; install the mobile app for at least one technician per vendor | Weeks 2 to 3 |
| 4. Run four weeks | All work orders to the ten issue only through the portal; the portal owner logs every question and every rejection reason | Weeks 3 to 6 |
| 5. Fix what they found | Configuration changes for the recurring problems (matching rules, required fields, notifications, document reminders); write the two-page vendor guide from the questions asked | Weeks 7 to 8 |
| 6. Measure behaviour | Share of work orders accepted in the portal and share of invoices submitted through it, by vendor; target 90%+ for the pilot ten before extending | Week 8 |
| 7. Extend by trade | Add the remaining vendors one trade at a time, using the pilot vendors in that trade as the reference; onboarding call for each | Weeks 9 to 20 |
| 8. Set the cut-over date | Publish a date after which emailed invoices are returned with instructions, and after which work orders are not confirmed by phone; give at least 60 days' notice | Announced at week 12; effective at week 20 or later |
| 9. Keep the deal | Pay portal invoices on the promised terms every month; the first late payment undoes the rollout | Ongoing |
A rollout on this shape reaches most of the invoice volume in about five months, because the high-volume vendors go first and the long tail of occasional vendors is picked up at the cut-over. The vendors who never adopt are usually the ones with a handful of jobs a year, and the emergency roster and the per-job tier are the right place for them.
What to require before mandating
A mandate is the last step, not the first, and it only holds when five things are true.
The payment promise is real and kept: portal invoices are paid on the published terms, every month, with the payment date visible in the portal, because the deal is the reason the mandate is accepted. Work orders issue only through the portal, so that a vendor who is not on it does not receive work; that is the mandate, and it needs no letter. Technicians have a mobile path that works on site, so the evidence requirement is achievable. Documents are held once with reminders, so the portal reduces the vendor's paperwork rather than adding to it. And a named person on the operator's side answers vendor questions inside a day and has the authority to change the configuration when the same question comes up three times.
With those in place, the mandate is a date and a sentence: from this date, work is issued and invoices are accepted through the portal. Without them, it is a letter that 60% of vendors will file with the last one.
Key facts
- A vendor portal in property management has four jobs: deliver the work order, confirm completion with evidence, take the invoice against the work order, and show payment status (RIOO's four-job test).
- RIOO's rule is that a portal is a deal, not a mandate: vendors adopt it when it pays them faster and asks them to type less.
- Vendors expect faster and visible payment, no re-keying, clear scope and approval before work, a mobile path for the technician, documents held once with reminders, immediate rejection reasons, and a human who answers inside a day.
- Adoption should be measured as the share of invoices submitted through the portal and the share of work orders accepted there, not as the share of vendors who have logged in.
- In the worked example, 40% adoption left 228 emailed invoices a month to re-key at twelve minutes each, about 45.6 hours of accountant time monthly.
- The rollout that works starts with a pilot of ten high-volume vendors onboarded by hand, fixes what they find, extends by trade, and sets a cut-over date with at least 60 days' notice.
- Work orders that issue only through the portal are the mandate; no letter is needed once the deal is in place.
The portal in the system
Whatever the vendor sees, the operator's side is a set of records: the work order with its priority and assignment, the status changes as it moves, the completion evidence, the invoice matched to the purchase order, and the payment. A vendor-facing channel is only as good as the record it writes to and reads from; a portal bolted onto a payment system that does not know about work orders cannot pre-fill an invoice or show a meaningful status, which is why so many of them stall.
In RIOO on NetSuite, work orders are created, prioritised, assigned to technicians or vendors and monitored to completion in service request and task management, which also centralises vendor communication, documentation and task assignments. On the payment side, vendor management and accounts payable holds each supplier's profile with its payment terms and payment history, converts scanned invoices to digital text, matches invoices against the purchase order and receipt, flags duplicates before approval, and schedules payments by due date or discount rule. Those are the records a vendor-facing channel reads from and writes to. How the AP side of that flow pays for itself is in our post on automating accounts payable for property management teams.
Put the deal to work. Before you write to a single vendor, decide the payment terms you will offer for portal invoices and whether you will keep them; that decision is the rollout. To see how work orders, vendor records and invoice matching sit in one system, book a walkthrough of RIOO's service request and task management.
Frequently asked questions
Q1. What is a vendor portal in property management?
A vendor portal property management teams use is the vendor-facing channel through which contractors receive work orders and purchase orders, accept them, confirm attendance and completion with photos and sign-off, submit invoices against the work order, and see the status of approval and payment. It is the vendor's side of the dispatch and payment stages of the vendor lifecycle.
Q2. Why do vendors not use the portal?
Because it adds work without paying them back. The common causes are payment on the same terms as email, invoices that have to be typed from scratch, work still arriving by phone, rejections with no visible reason, no mobile path for the technician, repeated document demands, and nobody having shown the office manager how it works. Each has a fix, and the first fix is a real payment promise for portal invoices.
Q3. How should adoption be measured?
By behaviour, not logins: the share of invoices submitted through the portal and the share of work orders accepted there, reported by vendor and by trade. A vendor who logged in once in March is not an adopter. The invoice share is the number that converts into accountant hours saved and matching errors avoided.
Q4. How do you roll out a vendor portal?
Pilot with ten cooperative, high-volume vendors across several trades; agree the deal (faster payment, pre-filled invoices, payment visibility); onboard each by hand with a short call and a first invoice submitted together; run four weeks with work orders issued only through the portal; fix the recurring problems; measure invoice and work-order share; extend by trade; then publish a cut-over date with at least 60 days' notice after which emailed invoices are returned.
Q5. Should a portal be mandatory?
Eventually, and by design rather than by letter: once work orders issue only through the portal, a vendor who is not on it does not receive work, which is the mandate. Before that, five things need to be true: the payment promise is kept, work is issued only through the portal, technicians have a mobile path, documents are held once with reminders, and a named person answers vendor questions inside a day.
Note: Figures in the examples are illustrative planning numbers, not benchmarks.
Related reading
- Vendor management in property management: the lifecycle guide
- Vendor SLA for property management: template with the three clocks
- Vendor onboarding checklist for property management
- Vendor scorecard for property management: how to measure contractor performance
- COI tracking for property managers: what a certificate actually proves
- Automating accounts payable: a time-saver for busy property management teams
