RD Multiservices
Proposal Template Matching
Designed a verification flow that lets sales agents generate the right proposal template automatically from CRM data — replacing manual template selection entirely.
COMPANY
RD Multiservices
ROLE
Product Designer
EXPERTISE
UX design, user flow, stakeholder alignment
PROJECT TIME
2 weeks
Project Overview
RD Multiservices is a facility services company based in Barendrecht, expanding from Cleaning into three new service entities: Security, Hospitality, and Property. Each entity has its own set of proposal templates — Cleaning alone has more than seven templates.
Overview
A follow-up to the Proposal Onboarding App. With new services launching, the app had no way to know which template fit a deal.
My role
Owned the end-to-end flow design, two UI directions, error strategy, and open-question framework for developer and manager alignment.
Project goal
Owned the end-to-end flow design, two UI directions, error strategy, and open-question framework for developer and manager alignment.
Zero manual proposals
When Security, Hospitality and Property go live, every proposal comes from the app
The system decides, the human verifies
Template selection is automated from CRM data. A mandatory confirmation step keeps a human check on it.
No dead ends
Every error an agent can hit — wrong ID, missing field, no template match — has a clear recovery path.
Why not just let sales pick a template?
The matching problem
The app had no way to know which template fits a deal. Deal type, entity, and service each change which template applies — Glasbewassing alone has separate recurring and one-time versions.
The human error problem
Manual selection is exactly where errors creep in. A wrong template means a wrong proposal reaching a client. The safest design removes the choice, not the human.
Research / Discovery
15+ templates
for Cleaning, Security, Property, Hospitiality
3 fields
determine the template
manual
proposals after go-live
Mapping the Cleaning templates revealed the logic hiding in the data: Glasbewassing and Tapijt reiniging each exist in recurring and one-time versions. That meant Deal Type isn’t just contract metadata.
The flow, before
Login
Deal ID
Check fields
Nobody
confirm
Generate
The flow, after
Login
Deal ID
Check fields
Human confirmation
Generate
The confirmation step that wasn’t there
While reviewing my flow against the briefing, I noticed my “confirm template type” step was actually a system check, not a human action. The flow validated that fields existed — but no screen asked the sales agent “is this data correct?” The fix was an explicit confirmation screen between the field check and the mapping check.
Design
I designed two UI directions using only existing design system components. The deciding factor wasn’t taste — it was usage context: daily power users favor speed, while occasional users benefit from more guidance.
Variant 1 — Simple
One centered card per step. Fastest for daily, repeat use and closest to the app’s existing minimal patterns.
Variant 2 — Split
A brand/help panel on the left gives contextual guidance, like where to find the Deal ID, next to the input field.
We went with Variant 2.
I assumed daily users would want the fastest option — but the team is growing. Variant 2 matches the new RD website, and its side panel teaches new agents as they work. No training needed.
STEP 1
Start with the Deal ID
The agent starts with a single known value from Pipedrive. Keeping this step focused reduces the chance of entering or editing data in the wrong place.
STEP 2
Verify the CRM fields
The app shows the values that determine the template. If a required field is missing, the error stays attached to the field and points the agent back to Pipedrive.
Wrong Deal ID
STEP 3
Confirm the matched template
The last step separates source data from the system’s conclusion. The agent confirms the values, sees the matched template, and gets a recoverable error if the combination has no template.
Template confirmed
No template match
Missing field
Showing the system’s conclusion
Displaying the matched template name as a read-only fourth item gives agents a final sanity check without reintroducing manual selection. Source data and system output stay visually distinct: what you verify vs. what the system decided.
Error Handling Strategy
Each error type gets a distinct visual pattern, so agents can tell them apart at a glance. Field-level issues get inline treatment. Combination-level issues get a banner because no single field is wrong.
Deal ID not found
Inline error at the input field. Wrong number, try again.
Missing field
Inline error on the specific field. Fix at the source, return with the ID pre-filled.
No template match
A banner below the field group. All values are present — the combination has no match.
No template exists for this combination
Marking one field red would send the agent hunting in the wrong place. The banner makes it clear that the issue is the mapping, not the individual data.
Outcome
0 manual
Google Docs proposals target
1 click
from confirmation to proposal
3 errors
each with a recovery path
This project launches August 2026. Most of the design value was delivered before any UI was drawn: the flow architecture, the error taxonomy, and a structured set of open questions for the developer and manager.
Template preview
Showing what the matched template actually looks like was out of scope for V1. If agents want more confidence than a template name provides, preview is the natural V2 candidate.
Legacy deal migration
Service descriptions were historically free-text in Pipedrive. Reliable matching requires structured dropdown values, which raises the rollout question: migrate old deals, or apply the flow to new deals only?
