Django Partner Portal: Building a Secure B2B Order Management, Invoice Tracking, and Support Workflow Platform

Project: Django Web Application Development, B2B Partner Portal, ERP Integration, Invoice Tracking, Order Workflow Automation, and Customer Support Management

Duration: 22 weeks

NorthBridge Wholesale Group supplies consumer goods, packaging materials, office products, and trade inventory to more than 1,800 business customers across the United Kingdom and Ireland. The company operates a mixed sales model where larger accounts work with dedicated account managers, while smaller customers place recurring orders through email, phone calls, and spreadsheet templates. Over time, this process became difficult to manage. Customers expected faster order confirmation, invoice visibility, delivery status, and support responses, but NorthBridge's internal teams still depended on shared inboxes, manual order entry, spreadsheet logs, and separate ERP screens. The company did not need a full ERP replacement. It needed a secure Django-based portal that could sit above existing systems, provide customers with self-service access, and reduce repetitive manual work for sales, finance, and support teams.

NorthBridge's customer operations were slowed by manual communication and disconnected workflows. Customers emailed order spreadsheets, asked account managers for invoice copies, requested delivery updates through support tickets, and called finance teams for account statements. Internal teams repeatedly copied information between inboxes, spreadsheets, ERP screens, and support notes. This created delays, inconsistent answers, duplicated work, and limited visibility for customers. As order volume increased, the manual process became too expensive and too error-prone to scale.

Business signals

• Customers had no self-service portal for viewing orders, invoices, delivery updates, account documents, and support requests.
• Sales teams spent too much time answering basic availability, pricing, order status, and invoice questions.
• Finance teams manually responded to repeated requests for invoice copies, credit notes, payment status, and account statements.
• Support tickets were tracked across email threads and spreadsheets, making ownership and escalation unclear.
• Account managers had limited visibility into customer portal activity because no portal existed.
• Customers often submitted orders using outdated spreadsheet templates with incorrect product codes or discontinued items.
• Order approval rules differed by customer but were handled manually by sales coordinators.
• New customer onboarding required repeated email explanations and manual document sharing.
• Leadership lacked clear reporting on support workload, order submission patterns, and customer self-service demand.
• The business wanted digital ordering but could not replace the ERP or rebuild every back-office process.

Technical signals

• Customer, product, price, invoice, and order data lived inside the ERP and had to remain authoritative there.
• ERP APIs were inconsistent and slower for some endpoints during business hours.
• Customer-specific pricing rules included contract pricing, volume bands, account discounts, restricted SKUs, and promotional exceptions.
• Some customers had multiple branches with different delivery addresses, buyer permissions, and approval requirements.
• Invoice PDFs and credit notes needed secure access control by customer account and user role.
• Existing order spreadsheets contained invalid product codes, duplicate lines, missing quantities, and outdated descriptions.
• Support requests needed file attachments, audit history, assignment, internal notes, and customer-visible comments.
• The portal required strong authentication, password policies, session controls, and role-based authorization.
• Internal users needed admin tools without exposing Django admin directly to all operational staff.
• ERP synchronization needed retry handling, failure visibility, and clear reconciliation logs.
• The application had to support future API access for larger customers.
• The deployment process needed automated testing, database migrations, logging, monitoring, and rollback safety.

Metrics Invoice Copy Requests: 420 to 560 requests per month

Finance Admin Workload: 2.5 to 3.5 hours per day spent on invoice and statement requests

Manual Order Entry Time: 7 to 12 minutes per emailed order

Order Template Error Rate: 14.8% of spreadsheet orders required manual correction

Customer Document Sharing: Handled manually through email attachments and shared folders

Support Ticket Visibility: No single live queue across email, phone, and account manager requests

Weekly Reporting Preparation: 5 to 7 hours per week across sales operations and support leads

Customer Order Status Requests: 900+ emails and calls per month

New Customer Portal Availability: No digital self-service portal existed

Average Support First Response Time: 18 to 26 business hours

Pages Measured

• Customer order submission process
• Invoice request workflow
• Order history lookup
• Support ticket handling
• Customer account document sharing
• Product availability requests
• Credit note lookup
• Account statement request process
• Branch user management
• Weekly customer operations reporting

Primary Audience: B2B customers, account managers, finance users, sales coordinators, support agents, and operations leadership

Measurement Window: 60 days before implementation

The discovery process focused on understanding customer workflows, internal operational pain points, ERP constraints, security requirements, and the minimum set of portal features that would deliver measurable business value. The team confirmed that Django was a strong fit because NorthBridge needed a secure data-driven web application with complex permissions, admin workflows, relational data models, background jobs, and integration with existing systems.

What we inspected

• Title: Stakeholder interviews

  Description: The team interviewed account managers, finance users, sales coordinators, support agents, IT administrators, warehouse operations, and a sample of high-volume customers. Each group explained which requests were repetitive, which information customers needed most often, and which workflows caused delays.

• Title: Customer journey mapping

  Description: The project mapped the full customer lifecycle from login, account selection, product search, order creation, basket review, approval, order submission, invoice lookup, delivery status review, support request creation, and document download.

• Title: ERP capability review

  Description: ERP endpoints were reviewed for product data, customer accounts, price lists, stock availability, order creation, invoice history, credit notes, delivery references, and account balances. The team documented API latency, required parameters, failure modes, and synchronization limits.

• Title: Permission model design

  Description: Customer roles were defined for account administrators, buyers, approvers, finance users, branch users, and read-only users. Internal roles were defined for support agents, account managers, finance staff, sales operations, and administrators.

• Title: Order workflow analysis

  Description: Existing order spreadsheets, email formats, account manager notes, and ERP order entry screens were reviewed. The team identified validation rules that could prevent common ordering mistakes before orders reached internal teams.

• Title: Invoice and document access review

  Description: Finance workflows were reviewed to determine which invoice PDFs, credit notes, account statements, delivery documents, and customer contracts could be made available through secure portal access.

• Title: Support process review

  Description: The team reviewed how support requests were created, assigned, escalated, resolved, and reported. The discovery showed that support needed a structured ticket model rather than another shared inbox.

• Title: Technical architecture planning

  Description: The team selected Django for the core portal, Django REST Framework for API endpoints, PostgreSQL for relational data, Celery and Redis for background synchronization, and Docker-based deployment for consistent environments.

The main challenge was to build a Django application that improved customer experience without disrupting the existing ERP, finance, warehouse, and account management processes. NorthBridge's ERP remained the source of truth for products, prices, stock, invoices, and customer account rules. The portal had to respect complex customer-specific pricing, credit limits, order approval rules, delivery restrictions, VAT handling, backorder logic, and document access permissions. The application also needed to support different user roles inside each customer company, such as buyers, finance users, branch managers, and administrators. Security, auditability, and reliability were critical because the portal would expose sensitive commercial data, invoice history, order records, and account-level documents.

The solution was a secure Django-based B2B partner portal that gave customers self-service access to ordering, invoices, account documents, delivery information, and support requests. The portal did not replace the ERP. Instead, Django became the customer-facing workflow layer that validated requests, synchronized data, controlled permissions, and reduced manual communication.

Strategy

• Build a Django portal with customer-specific authentication, account selection, and role-based access.
• Use PostgreSQL to store portal users, permissions, cached ERP data, support tickets, audit logs, and workflow state.
• Integrate with the ERP for products, prices, stock, customer accounts, invoices, credit notes, and order submission.
• Use Celery workers for background synchronization, document refreshes, email notifications, and retryable ERP tasks.
• Create a customer order workflow that validates product codes, quantities, account restrictions, pricing, delivery addresses, and approval rules before ERP submission.
• Provide invoice and credit note lookup with secure PDF download permissions.
• Replace spreadsheet support tracking with a structured ticket module.
• Create internal dashboards for support workload, customer activity, order issues, and finance request reduction.
• Add audit logging for sensitive actions such as invoice downloads, order submission, user role changes, and document access.
• Deploy the system with automated tests, CI checks, logging, monitoring, and rollback-friendly migrations.

Phase1 Title: Django project foundation and domain model

Actions

• Created separate Django apps for accounts, customers, catalog, orders, invoices, documents, support, integrations, notifications, and reporting.
• Designed PostgreSQL models for customer accounts, branches, portal users, roles, permissions, products, price records, baskets, orders, invoices, support tickets, attachments, and audit events.
• Added environment-based settings for local development, staging, and production.
• Configured custom Django user models to support customer users and internal users cleanly.
• Created database constraints for account relationships, branch ownership, unique ERP references, and document access mapping.
• Added model-level validation for role assignments, branch access, and customer account boundaries.
• Configured structured logging from the beginning to support debugging during ERP integration.
• Added pytest, factory fixtures, and initial test coverage for core models and permission behavior.

Description: The first phase established the Django application structure, relational data model, environment configuration, and core business entities. The team focused on building a maintainable foundation before adding customer-facing features.

Phase2 Title: Authentication, authorization, and account security

Actions

• Implemented secure login, password reset, session expiry, and account lockout policies.
• Added optional two-factor authentication for customer administrators and internal users.
• Created role-based access controls for buyers, approvers, finance users, account administrators, branch managers, and read-only users.
• Restricted invoice and document access by customer account, branch, and role.
• Added internal staff permissions for support, finance, account management, and portal administration.
• Created audit logs for login events, failed login attempts, order submissions, invoice downloads, user invitations, permission changes, and support ticket updates.
• Added middleware to enforce account context selection for users linked to multiple customer accounts.
• Built admin-friendly screens for inviting users, disabling accounts, resetting access, and reviewing user activity.

Description: Security was treated as a core feature rather than a final checklist. The portal needed strict separation between customer accounts and reliable controls for sensitive finance data.

Phase3 Title: ERP data synchronization

Actions

• Created ERP API clients for customer accounts, products, price lists, stock availability, invoices, credit notes, delivery references, and order creation.
• Used Celery tasks to sync product catalog, pricing records, invoice metadata, and account balances on scheduled intervals.
• Cached frequently used ERP data in PostgreSQL with source timestamps and synchronization status.
• Added retry handling for temporary ERP API failures.
• Created dead-letter records for failed ERP tasks that required manual review.
• Tracked API latency, row counts, sync duration, failure reasons, and last successful sync time.
• Separated full synchronization jobs from incremental updates.
• Added management commands for forced resyncs during support and deployment scenarios.
• Created reconciliation reports comparing portal records against ERP source counts.

Description: The portal depended on accurate ERP data, but the ERP could not be queried live for every page view. The team built a controlled synchronization layer that balanced freshness, performance, and reliability.

Phase4 Title: Product catalog and customer-specific pricing

Actions

• Built product listing, search, filtering, category browsing, and product detail pages.
• Added customer-specific visibility rules for restricted SKUs and contract-only products.
• Displayed pricing based on customer account, contract terms, volume bands, active promotions, and ERP price lists.
• Added stock availability indicators with clear wording to avoid overpromising exact warehouse quantities.
• Handled discontinued products, substitute products, minimum order quantities, and pack-size rules.
• Added server-side validation so customers could not bypass pricing or restriction rules through client-side changes.
• Created internal tools for reviewing catalog sync issues and missing price records.
• Optimized database queries with indexes, select-related usage, prefetching, and cached computed price lookups.

Description: The catalog experience needed to show each customer only the products they were allowed to buy, with the correct pricing and availability rules.

Phase5 Title: Basket, order validation, and approval workflow

Actions

• Built basket functionality for adding products, updating quantities, saving drafts, and reordering from previous orders.
• Validated product availability, minimum quantities, pack sizes, delivery address rules, customer restrictions, and price changes before checkout.
• Added branch-level delivery address selection with customer administrator controls.
• Created buyer and approver roles for accounts requiring internal customer approval before submission.
• Added approval queues for orders exceeding spend thresholds or containing restricted products.
• Generated clear validation messages for invalid product codes, discontinued items, unavailable quantities, and account restrictions.
• Submitted approved orders to the ERP through a controlled integration task.
• Stored ERP order references, submission status, failure reasons, and retry history.
• Sent order confirmation emails to customer users and internal account teams.
• Created internal exception views for orders that failed ERP submission.

Description: The order workflow was designed to reduce manual correction before orders reached sales coordinators. Django handled validation, approval, and ERP submission rules before the order became official.

Phase6 Title: Invoice, credit note, and account document module

Actions

• Built invoice search by invoice number, order reference, date range, branch, status, and amount.
• Added secure PDF download for invoices, credit notes, delivery notes, and account statements.
• Stored document metadata in Django while retrieving or refreshing files through secure ERP and document storage integrations.
• Restricted finance documents to users with finance, administrator, or approved read-only permissions.
• Added audit events for every document download.
• Displayed payment status, invoice due dates, credit note references, and account balance summaries where ERP data was available.
• Created customer-facing explanations for pending, paid, overdue, credited, and partially credited statuses.
• Reduced repeated finance emails by allowing customers to retrieve documents directly from the portal.

Description: Finance-related self-service was one of the highest-value portal features because customers frequently requested copies of documents that already existed inside internal systems.

Phase7 Title: Support ticket workflow

Actions

• Created customer-facing ticket forms for delivery issues, invoice questions, product problems, order changes, account access, and general support.
• Added ticket categories, priorities, statuses, assignment, due dates, and escalation flags.
• Allowed customers and staff to attach files such as photos, delivery notes, damaged item evidence, and invoice screenshots.
• Separated customer-visible comments from internal-only notes.
• Added notification emails for ticket creation, assignment, customer replies, status changes, and resolution.
• Created internal queues for support agents, finance users, account managers, and operations teams.
• Added SLA timers for first response and resolution targets.
• Created ticket history so users could see what changed, who changed it, and when.
• Built filters for customer, branch, category, priority, status, owner, and overdue tickets.

Description: The support module replaced scattered email tracking with a structured Django workflow for customer requests, internal ownership, attachments, comments, and escalation.

Phase8 Title: Customer dashboard and internal operations views

Actions

• Created a customer homepage showing recent orders, open support tickets, unpaid invoices, saved baskets, and important account documents.
• Added quick links for reorder, invoice search, ticket creation, and document downloads.
• Built internal dashboards showing portal adoption, order submission volume, ERP failures, support workload, overdue tickets, and finance request reduction.
• Added account manager views showing customer activity, recent orders, open issues, and document usage.
• Created finance views for invoice lookup trends, overdue document access, and high-volume customer requests.
• Added exportable reports for operational review meetings.
• Used HTMX for lightweight dynamic interactions without turning the portal into a complex single-page application.
• Optimized key dashboard queries with database indexes and cached summary tables.

Description: The portal included simple dashboards for customers and practical operational views for internal teams. The goal was not decorative analytics but faster daily action.

Phase9 Title: API layer and future customer integrations

Actions

• Created authenticated API endpoints for product lookup, account catalog access, draft order creation, order status, invoice metadata, and support ticket creation.
• Used token-based authentication for approved customer integrations.
• Added throttling, pagination, filtering, and serializer-level validation.
• Reused the same business rules from the portal checkout flow to avoid separate logic for API orders.
• Created API audit logs for customer requests and order submission attempts.
• Documented endpoints for future customer onboarding.
• Added automated tests for permission boundaries, invalid payloads, restricted products, and order validation behavior.
• Kept API rollout controlled to avoid creating support burden before the core portal was stable.

Description: Some larger customers wanted future system-to-system ordering. The first release focused on the portal UI, but the architecture included API readiness through Django REST Framework.

Phase10 Title: Testing, deployment, monitoring, and rollout

Actions

• Added unit tests for pricing rules, role permissions, order validation, invoice access, ticket workflow, and ERP integration clients.
• Added integration tests for order submission, invoice synchronization, support ticket notifications, and document downloads.
• Configured GitHub Actions for linting, testing, migrations checks, and build validation.
• Containerized the application using Docker for consistent local, staging, and production environments.
• Deployed Django behind Nginx and Gunicorn with PostgreSQL, Redis, and Celery workers.
• Configured Sentry for error monitoring and structured application logs for operational visibility.
• Added database backup procedures and migration rollback plans.
• Ran a pilot with 40 customer accounts before expanding access to the wider customer base.
• Created training guides for customers, account managers, finance users, and support agents.
• Collected feedback during rollout and improved wording, filters, validation messages, and dashboard layout.

Description: The final implementation phase focused on reliability, maintainability, and adoption. The portal was rolled out in stages so business teams could compare results and train customers gradually.

• Manual order entry workload decreased because customers could submit validated orders directly through the portal.
• Order template errors dropped significantly because product codes, quantities, pack sizes, and account restrictions were validated before submission.
• Invoice copy requests to the finance inbox decreased as customers gained secure self-service access to invoices and credit notes.
• Average support first response time improved because tickets were assigned, prioritized, and tracked in one structured workflow.
• Customers gained a single place to view recent orders, invoice history, account documents, support requests, and saved baskets.
• Account managers gained better visibility into customer activity without asking operations teams for manual reports.
• ERP order submission failures became visible through structured logs, retry history, and exception queues.
• Finance users spent less time attaching invoice PDFs to emails and more time handling higher-value account questions.
• Support teams gained ownership visibility, internal notes, customer-visible comments, and escalation tracking.
• Customer administrators could manage branch users and permissions without relying on manual IT requests for every small change.
• Internal reporting improved because portal activity, support workload, order issues, and document downloads were captured in PostgreSQL.
• The company reduced dependency on shared inboxes, spreadsheet logs, and repeated customer status emails.
• The Django codebase became maintainable through tests, modular apps, CI checks, logging, and clear deployment workflows.
• NorthBridge gained a scalable digital foundation for future customer APIs, advanced ordering features, and deeper ERP automation.

The Django partner portal gave NorthBridge a practical digital layer over its existing ERP and customer operations processes. Customers received faster self-service access to orders, invoices, documents, and support. Internal teams reduced repetitive manual work, improved visibility, and gained a structured platform for future B2B digital services.

Outcomes

• Reduced manual workload for sales coordinators, finance teams, and support agents.
• Improved customer experience through self-service order, invoice, and support access.
• Fewer order errors because validation happened before ERP submission.
• Better account control through role-based permissions and branch-level access.
• Improved finance efficiency by reducing repeated invoice and credit note requests.
• More reliable support operations through structured ticket queues and escalation rules.
• Stronger auditability for sensitive actions such as invoice downloads and role changes.
• Better operational reporting from portal usage, support activity, and order workflow data.
• Lower risk compared with ERP replacement because the portal integrated with existing systems.
• A reusable Django foundation for future customer integrations, API ordering, and advanced account services.

• Use Django instead of a lightweight microframework.

  The project required authentication, permissions, admin workflows, relational data models, forms, validation, background jobs, and secure business logic. Django provided these foundations faster and more reliably than assembling them separately.

• Keep the ERP as the source of truth.

  Replacing the ERP would have introduced unnecessary cost and operational risk. The portal solved the customer workflow problem while preserving existing finance, stock, pricing, and order management processes.

• Cache ERP data in PostgreSQL instead of querying the ERP on every page request.

  Live ERP calls were too slow and inconsistent for a good portal experience. Controlled synchronization improved performance while keeping source timestamps and reconciliation visibility.

• Use Celery and Redis for background workflows.

  ERP synchronization, document refreshes, notifications, retry handling, and order submission tasks needed to run reliably outside the request-response cycle.

• Build role-based permissions around customer account context.

  Many customers had multiple branches and different user responsibilities. Account-aware authorization prevented users from seeing invoices, orders, documents, or tickets outside their permitted scope.

• Validate orders before ERP submission.

  The portal needed to reduce internal correction work. Server-side validation caught invalid products, restricted SKUs, wrong quantities, inactive addresses, approval requirements, and pricing issues before orders entered the ERP.

• Use HTMX for selected interactive screens.

  The team wanted a responsive user experience without the complexity of maintaining a full single-page application. HTMX supported dynamic basket updates, filters, and inline actions while keeping Django templates productive.

• Create structured support tickets instead of integrating only with email.

  Email alone could not provide ownership, status, escalation, internal notes, reporting, or customer-visible history. A ticket model gave the business a measurable workflow.

• Add audit logging from the first release.

  The portal exposed sensitive customer and finance information. Audit logs were necessary for security reviews, customer disputes, internal accountability, and compliance expectations.

• Pilot with selected customers before full rollout.

  The portal changed customer behavior and internal workflows. A staged rollout allowed the team to catch usability issues, permission edge cases, and ERP synchronization gaps before broad launch.

• Django works well for B2B portals because business rules, permissions, forms, admin tools, and relational data are central to the problem.
• A customer portal should not blindly expose ERP data; it needs a workflow layer that validates, explains, and protects information.
• Role design is one of the most important parts of a B2B application because customer companies rarely have only one type of user.
• ERP integration should include retries, sync logs, reconciliation tools, and failure queues from the beginning.
• Self-service invoice access can remove a large amount of repetitive finance workload.
• Order validation creates more business value when it prevents errors before they reach internal teams.
• Support workflows need ownership and status visibility, not just message collection.
• Audit logging should be treated as a product feature when sensitive financial and customer data is involved.
• A portal does not need to be a full single-page application to feel modern and efficient.
• Pilot customers reveal permission, wording, and workflow issues that internal teams often miss.
• Caching external system data improves speed, but every cached record needs source timestamps and refresh rules.
• The best B2B portals reduce communication friction without hiding important exceptions or approval steps.

Role: Head of Digital Operations

Quote: The portal gave our customers the visibility they had been asking for and gave our internal teams breathing room. Django let us build a secure workflow layer around our ERP instead of forcing a risky system replacement.

Person: Amelia Grant

Company: NorthBridge Wholesale Group

NorthBridge Wholesale Group used Django to create a secure B2B partner portal for ordering, invoice access, account documents, support tickets, branch permissions, and ERP-connected customer workflows. The project avoided replacing the ERP and instead introduced a reliable customer-facing application layer with PostgreSQL, Django REST Framework, Celery, Redis, role-based permissions, audit logging, background synchronization, and structured operational dashboards. The result was less manual work, fewer order errors, faster customer service, stronger finance self-service, improved support visibility, and a scalable foundation for future digital commerce and API-based customer integrations.