A B2B customer portal budget depends on what customers can do, which records they can access and how reliably the portal must communicate with your business systems. A document library for existing customers and a portal that accepts orders against live contract prices are different projects, even if their homepages look similar.
For a UK SME, the strongest starting point is one expensive customer-service interaction. That might be retrieving invoices, checking delivery status or repeating a previous order. Define the task, the systems involved and the result the customer should receive. Then budget for the complete journey, including the staff who will support it when something goes wrong.
Start with a bounded customer journey
Write a first-release statement that can be demonstrated. For example: an authorised contact signs in, sees invoices belonging to their company and downloads an agreed document. Include account invitation, forgotten access and the route for reporting an incorrect record. These supporting steps make the feature usable; they are not optional finishing touches.
List what the first release excludes. Ordering, payments, credit-limit changes and organisation-wide administration can each introduce additional rules. If customers will still telephone for those tasks, explain that clearly in the service design. A focused portal can be useful without pretending to replace every conversation with your team from the first day.
Use our B2B portal requirements template to organise the scope before requesting prices. Give suppliers the same journeys and exception examples. Otherwise one quote may cover a demonstration using sample data while another includes identity, production integration, customer onboarding and operational support.
Users and permissions influence more than licence counts
Distinguish customer companies from individual users. One company may have several branches, buyers and finance contacts, each with different access. Decide who can invite colleagues, remove access and approve a new relationship between a person and a business account. Those decisions influence both implementation and the administrative workload after launch.
Ask whether a user can belong to more than one company and how they switch context. Define access to invoices, contracts, prices and attachments separately where the business requires it. Test with two unrelated customers: changing a record identifier or following a document link must not reveal the other customer's information.
In Power Pages, Microsoft documents table permissions associated with web roles. A bespoke portal needs its own equivalent access design. Budget for testing the permissions at the data and download boundaries, not merely hiding menu items. A polished customer interface does not prove that records are isolated correctly.
Integration is often the largest uncertainty
List each system the portal will read or update, starting with the ERP or accounting application. Ask who provides access, whether a suitable API exists, what test environment is available and whether the current licence permits the proposed use. Include any work that must be purchased from the incumbent software provider.
Define the freshness requirement for each piece of information. An invoice archive may tolerate a scheduled refresh, while stock allocation needs a different decision. Showing the last successful update time can help users understand a delay. If the ERP is unavailable, specify which portal features remain useful and which must pause with an understandable explanation.
Writing data back is a separate scope item. A repeat order needs validation of current prices, availability and permissions, plus a way to recognise retries without duplicating the order. Staff need to find requests that were accepted by the portal but not completed by the ERP. Include reconciliation and recovery in the estimate for business integrations.
Break the one-off budget into visible work
Ask suppliers to separate discovery, user experience, identity and permissions, integration, application development, testing, launch and training. Request deliverables for each part. Discovery should leave documented decisions and investigated uncertainties; testing should include representative users, realistic data and failure cases. A broad line labelled “portal development” makes competing proposals difficult to assess.
Content and data preparation also require time. Someone must decide which documents customers can see, correct account relationships and resolve duplicate contacts. Agree who owns this work and how it affects the release date. Include invitation emails, help content and an accessible route to support so the launch does not depend on staff explaining every screen individually.
Keep contingency linked to named uncertainty. If an ERP connection has not been tested, ask for a small investigation before committing to the full build. Where a reserve remains necessary, state how it is authorised and reported. Do not treat every unknown as automatically covered by a percentage added to an otherwise incomplete proposal.
Model recurring costs using actual usage assumptions
The operating budget may include platform licences, hosting, database storage, file storage, monitoring, backups, email delivery and support. Check which items are included in a managed platform and which remain your responsibility. Include non-production environments where they are needed to test changes safely before customers see them.
Licensing measures vary. Microsoft's Power Platform licensing FAQ describes Power Pages capacity based on user type and website usage. If that platform is proposed, ask the supplier to model your expected pattern under the current terms. Do not assume the number of registered contacts equals the billable measure, or reuse an old price without checking it.
Ask for a current-volume scenario and a growth scenario. Include active customer contacts, document volume, peak requests and expected integrations. For a bespoke application, user growth may affect infrastructure differently from a per-user platform. Compare the whole operating model rather than treating the absence of one particular licence fee as the absence of ongoing cost.
Include support and adoption in the business case
Decide who handles customer access problems, incorrect records, failed orders and ERP outages. Agree support hours, escalation, incident communication and the boundary between a fault and a feature request. A portal creates another service channel, so its cost includes helping people use it and investigating cases that cross several systems.
Treat efficiency estimates as assumptions to validate. In an invented example, three hundred monthly document requests at six minutes each represent thirty staff hours. If sixty per cent move successfully to self-service, eighteen hours is the theoretical avoided handling time before accounting for portal administration and exceptions. These are illustrative inputs, not a forecast of savings for your business.
Measure adoption and successful completion after launch. Track whether customers find the right document without contacting support, whether orders reach the ERP and whether staff still perform duplicate checks. Released staff time is useful only if the business can redirect it. Customer satisfaction and repeat business deserve measurement rather than an automatic revenue claim.
Ask for a proposal you can operate after launch
Compare options over the same period and with the same scope. Show one-off delivery cost, recurring service cost and expected change allowances separately. For a UK buyer, ask whether amounts are in pounds, how VAT and expenses are presented and which third-party fees can change. Confirm who controls the domain, hosting account, application configuration and customer data export.
Worktechlabs can help plan and build customer-facing business software connected to your ERP processes. Bring the customer task creating the most repeated work, examples of the records involved and the current source system. Discuss your portal project to define a first release with a clear integration boundary, a realistic operating budget and a measurable customer outcome.
Official sources and further reading
