Configuration, never customisation, means every difference between companies lives in settings: fields, policies, templates, workflow rules and scoring models. No customer gets a code fork. It is one of ten rules iProcure is built by. Together they decide what we build, what we refuse, and how the product stays one product for everyone who uses it.
The rules are written into our product plan, and every feature is checked against them. If a feature breaks one, the feature loses. Here they are, with what each one means in practice.
Why does configuration beat customisation?
Customisation feels like service. A customer asks for a special approval step, a vendor writes code for that customer, and the request is closed. A year later that customer is on a branch of the product nobody else runs. Upgrades break it, fixes skip it, and the next vendor release is a migration project.
Configuration answers the same request differently. The special approval step becomes a workflow rule the customer's admin can see, change and audit. The next customer who needs something similar changes a setting, not a codebase. Everyone stays on one version.
For a buyer, the test is simple: ask a vendor whether your requirement will be a setting or a code change. If it is code, ask who maintains it after go-live.
What are the ten rules?
1. Suppliers must never learn who else is invited.
Supplier-blind is enforced by the product, not left to a setting or to anyone's memory. No shared recipient lists, and no participant names or counts anywhere a supplier can see. We explain why in supplier-blind by construction.
2. Email is a working surface, not just a notification.
Anything a leader must decide or review can be done from the email, on a phone. Approvals, replies and clarifications happen in the inbox and land on the record. The portal is where work is prepared, not the only place it can be finished. More in why leaders won't live in your procurement portal.
3. Configuration, never customisation.
Every company's differences are settings, not code forks: custom fields, policies such as who needs an NDA, templates, approval rules and scoring models. No customer branches and no special builds.
4. Starter kits suggest, never lock.
A category kit, such as IT services with a resource rate card, is a helpful first draft, not a template you fight. Every question, column, weight and word can be changed or removed, and the events you have already built stay as you left them.
5. No built-in bias towards price.
Quality and numbers are separate tracks, with a weighting you choose per event, starting from your organisation's default. No part of the product assumes price carries most of the weight, or that it exists at all: an RFI can be 100 to 0. See how this works in the eRFx module.
6. Region-neutral core, region packs at the edge.
One product for India, Europe, the USA and South Korea, with no per-country builds. Each country's tax IDs, rules and local channels come in a region pack that the organisation switches on.
7. Every module stands alone.
Buy two modules or nine. A module you did not buy simply is not there, rather than greyed out. Each module works on its own, getting what it needs from your existing systems instead.
8. Connect before replace.
Your records keep the IDs from your own systems, and everything can be imported and exported. You can import from and sit alongside what you run today, and replace it on your own timeline, or not at all.
9. AI shows its sources.
Every AI suggestion carries its result, its reasoning and its citations, and a human decides. AI works inside the step, citing the supplier's words; a human accepts or overrides; it never awards or signs. Our reasoning is in checkable AI, not more bots.
10. No fake numbers.
Every figure on a dashboard is computed from records, never typed in. And we are pre-launch, so we quote no customer results until we have them.
What happens when a feature breaks a rule?
The feature changes, or it does not ship. Two examples from our own plan:
- Going global. Early work assumed one country's tax IDs, currency and formats. When we set out to serve four regions, those moved into region packs, so one product now serves all four. That is rule 6 at work.
- The demo. Our sample screens once showed AI cards and badges for features that were not built. We removed them, so the demo only shows AI that is real. That is rules 9 and 10 at work.
How much of this is live today?
We say live, demo or roadmap truthfully.
- Live: approvals from a signed one-time email link, region packs for the four launch regions, and imports you can check first and undo after.
- Demo on sample data: approval rules you set up without code.
- Roadmap: self-serve configuration of fields and policies, and category starter kits.
How can you test us on these rules?
Bring your strangest requirement to a 10-minute demo and ask whether it is a setting. If you are comparing us with another vendor, our comparison pages say where they lead and where we do.