Noto Café
ACPQ - Transforming Enterprise Telecom Quoting
A greenfield platform for configuring and quoting Customer Premises Equipment - CPE; across complex multi-product, multi-site enterprise deployments - delivered in six months, alongside a live legacy system.
99.7%
Reduction in quote estimation turnaround
99.7%
Reduction in quote estimation turnaround
99.7%
Reduction in quote estimation turnaround
75%
Faster final offer generation
75%
Faster final offer generation
75%
Faster final offer generation
500+
Sites supported in a single deployment
500+
Sites supported in a single deployment
500+
Sites supported in a single deployment
My role
Responsibilities
Lead product designer with end-to-end ownership — research, workflow architecture, interaction design, and engineering handoff. Sole designer on the workstream for the full six months.
Responsibilities
Lead product designer with end-to-end ownership — research, workflow architecture, interaction design, and engineering handoff. Sole designer on the workstream for the full six months.
Responsibilities
Lead product designer with end-to-end ownership — research, workflow architecture, interaction design, and engineering handoff. Sole designer on the workstream for the full six months.
Duration & scope
6 months. Greenfield build for CPE configuration and quoting — a category with no prior dedicated tooling at BT. Shipped alongside a live legacy system still in active use by enterprise customers.
Duration & scope
6 months. Greenfield build for CPE configuration and quoting — a category with no prior dedicated tooling at BT. Shipped alongside a live legacy system still in active use by enterprise customers.
Duration & scope
6 months. Greenfield build for CPE configuration and quoting — a category with no prior dedicated tooling at BT. Shipped alongside a live legacy system still in active use by enterprise customers.
Cross functional team
Business analyst
Service designer
Product manager
Product owner
Content designer
The constraint that shaped everything:
We had six months to design and ship a platform complex enough to replace the legacy system — while that system remained live for enterprise customers mid-deal. Every design decision had to be clearly better than what people already knew, not just different.
The problem
CPE — Customer Premises Equipment - sits at the heart of enterprise telecom deployments. It covers the physical hardware installed at each customer location: routers, switches, firewalls, and the services layered on top. For a large enterprise, that means dozens of different product combinations across hundreds of sites, each with its own installation, maintenance, and compliance requirements.
The tools BT sales teams used weren't built for it. Spreadsheets, disconnected systems, and manual coordination meant quotes that took days - sometimes weeks - to assemble. But the real problem ran deeper than slow turnaround.
Pricing in enterprise telecom isn't static. It involves:
Currency fluctuation across multi-country deployments
Tariff and tax compliance rules varying by geography
Geographic restrictions on where BT can operate or offer specific services
Supplier pricing that changed between quote drafts
A manually assembled quote had no way to reflect any of this in real time. By the time a proposal reached a customer, it was already out of date - and if errors were present, they were discovered through manual effort, often after the quote had already been sent.
The core design challenge:
How do you design a system that handles genuine pricing complexity — tariffs, geography, multi-product compatibility — in a way that's fast enough to be useful and accurate enough to be trusted?
Discovery & framing
What we found, and what made it hard to find
I worked with the BA and service designer to map the existing process end to end. We shadowed sales agents mid-quote and interviewed account managers. We also deliberately involved technical experts, the people who performed manual compatibility checks, because they understood the product logic better than anyone.
The hardest discovery wasn't about tools.
Some technical experts and sales agents were reluctant to talk to us at all. The new platform represented a structural change - and for people whose value came from knowing how to navigate the complexity manually, it felt like a direct threat to their role. Adoption wasn't just a UX problem. It was a trust and behavioural change problem from the start.
Understanding that shaped everything - from how we ran research sessions to how we framed the platform's purpose. ACPQ wasn't positioned as a replacement for expertise. It was positioned as a way to apply that expertise faster and at greater scale. The complexity itself had four dimensions:
Multi-product
Each site needed different hardware, service tiers, and support. Not all combinations were valid, and manual compatibility checks relied entirely on technical expert knowledge.
Multi-product
Each site needed different hardware, service tiers, and support. Not all combinations were valid, and manual compatibility checks relied entirely on technical expert knowledge.
Multi-product
Each site needed different hardware, service tiers, and support. Not all combinations were valid, and manual compatibility checks relied entirely on technical expert knowledge.
Multi-site
Enterprise customers operated across hundreds of locations. Managing even moderate deployments meant tracking every site's configuration in parallel spreadsheets.
Multi-site
Enterprise customers operated across hundreds of locations. Managing even moderate deployments meant tracking every site's configuration in parallel spreadsheets.
Multi-site
Enterprise customers operated across hundreds of locations. Managing even moderate deployments meant tracking every site's configuration in parallel spreadsheets.
Pricing complexity
Live currency rates, tariff and tax rules, supplier pricing, and geographic eligibility all affected the final number - none of which the legacy tools could calculate in real time.
Pricing complexity
Live currency rates, tariff and tax rules, supplier pricing, and geographic eligibility all affected the final number - none of which the legacy tools could calculate in real time.
Pricing complexity
Live currency rates, tariff and tax rules, supplier pricing, and geographic eligibility all affected the final number - none of which the legacy tools could calculate in real time.
Legacy coexistence
Customers were mid-deal on the old system throughout our build. We couldn't force a cutover. Adoption had to be earned - and trust had to be built with people who weren't sure they wanted the change.
Legacy coexistence
Customers were mid-deal on the old system throughout our build. We couldn't force a cutover. Adoption had to be earned - and trust had to be built with people who weren't sure they wanted the change.
Legacy coexistence
Customers were mid-deal on the old system throughout our build. We couldn't force a cutover. Adoption had to be earned - and trust had to be built with people who weren't sure they wanted the change.
The adoption and transition challenge
Adoption and transition were treated as explicit design problems, not afterthoughts. We identified three categories of user resistance and designed for each:
Behavioural change
Users had deeply ingrained habits built around the legacy tools. The new workflow had to feel intuitive enough that switching didn't require relearning everything from scratch.
Users had deeply ingrained habits built around the legacy tools. The new workflow had to feel intuitive enough that switching didn't require relearning everything from scratch.
Structural change
Technical experts feared the platform would automate their specialist role away. We designed to augment their knowledge - surfacing their expertise as the system's logic - not replace it.
Transition path
With no hard cutover possible, users needed to trust the new system enough to choose it. Early wins on small deals built that confidence before teams moved complex deployments across.
Design approach
Structuring the workflow
The existing process had no shared structure. Every sales agents had their own method. My starting point was defining a workflow that codified best practice without feeling rigid to experts, and guided newer users without patronising them.
USER JOURNEY MAP
The journey below maps the sales agent's experience across both systems - showing exactly where the legacy process broke down and what ACPQ needed to deliver instead.
User flow - ACPQ end-to-end
The flow below shows the full path through ACPQ, including the three site-entry paths, the inline validation loop, and the pricing approval gate before offer generation.
What this looks like in practice - a 5-site deal
A sales agents quoting a UK retail chain with 5 branches and two different CPE requirements, using ACPQ's group structure to handle both configurations within a single quote.
Scenario - UK retail chain, 5 branches, mixed CPE requirements
Create the quote - Customer account attached, quote type set. ACPQ generates a quote reference and carries account details forward automatically.
Legacy: manually open multiple tools, create a spreadsheet, track the reference separately
Create two groups - rather than configuring 5 sites individually, the agents groups them by CPE requirement: 3 London branches, 2 Manchester branches
Legacy: no group concept - every site configured independently, no shared configuration inheritance
Add sites to each group - 3 sites into Group 1, 2 into Group 2. ACPQ flags one Manchester site as geo-restricted before any configuration begins. Agents resolves it here - not after a full quote has been built.
Legacy: geo restrictions discovered manually, often after hours of configuration work
Configure products once per group - Group 1 gets a router + firewall bundle applied to all 3 sites simultaneously. Group 2 gets an upgraded bundle with a high-throughput switch applied to both Manchester sites. Compatibility validated inline - no issues flagged.
Legacy: configure each site one by one; compatibility check needed a 30–60 min call with a technical expert
Price each group - Hardware costs, installation, and tariff-adjusted pricing calculated in real time per group. Agent adjusts the discount on Group 2 and sees the margin update immediately across both Manchester sites.
Legacy: manual cost calculation per site, pricing often stale by the time it reached the customer
Generate offer - One action produces a customer-ready quote with site-level breakdowns and group-level pricing across both configurations.
Legacy: 2–4 hours of manual formatting across tools, errors common in the final document
Key decisions and tradeoffs
Decision
Inline validation at the point of configuration. Compatibility issues surfaced immediately as users built out CPE product combinations - not at the final step. This added engineering complexity but directly addressed the most costly problem from research: errors found too late.
Decision
Geographic eligibility surfaced before configuration begins. A key finding from research was that geo restrictions - whether BT could operate in a given location - were often discovered after a full quote had been built. ACPQ flags eligibility at site entry, not at the end, preventing wasted configuration effort.
Tradeoff
Structure vs. flexibility in site management. Power users wanted total freedom; newer users needed guardrails. Hierarchical site grouping with bulk operations gave experts speed at scale while keeping the structure navigable. The tradeoff: a heavier data model and longer build, which created pressure under the six-month deadline. Some edge-case configuration paths were documented and deferred to v2.
Decision
Real-time pricing visibility at every step, not just the end. Margin and cost impact were surfaced throughout configuration, not on a final pricing screen. This changed how sales engineers made discount decisions - they could model scenarios in context. The PM flagged it as scope risk; I made the case it was the change most likely to end the spreadsheet habit.
Collaboration
Content design changed how the product felt. Working with the content designer, we replaced internal BT jargon with language that matched how sales engineers actually talked. This reduced the learning curve significantly - users could orient themselves without a manual.
Tradeoff
Designing for the expert user, not around them. Technical experts feared the platform would make their role redundant. The system was deliberately designed to encode their knowledge as its logic - compatibility rules, geo eligibility, pricing thresholds - so their expertise became the system's backbone, not something it replaced.
Key screens
The screens below show the three areas where the design decisions above were most visible to users.
Outcome
What changed
ACPQ shipped and became the active quoting platform for CPE deployments at BT. Quote estimation dropped by 99.7%. Final offer generation fell by 75%. Deployments of 500+ sites became manageable by sales teams directly - without specialist support.
The pricing complexity that made manual quoting so error-prone - currency fluctuation, tariff rules, geo restrictions - was now handled by the system. Sales agents could focus on the deal, not the calculation.
The adoption challenge proved real but manageable. Early wins on smaller deals - like the 5-site scenario above - built confidence. Technical experts who had been most resistant became advocates once they saw their knowledge encoded in the system's logic rather than replaced by it.
The metric I'm most proud of isn't on the headline list. Sales agents stopped double-checking quotes in spreadsheets after the fact. That was the real signal the platform had earned trust.
What changed
ACPQ shipped and became the active quoting platform for CPE deployments at BT. Quote estimation dropped by 99.7%. Final offer generation fell by 75%. Deployments of 500+ sites became manageable by sales teams directly - without specialist support.
The pricing complexity that made manual quoting so error-prone - currency fluctuation, tariff rules, geo restrictions - was now handled by the system. Sales agents could focus on the deal, not the calculation.
The adoption challenge proved real but manageable. Early wins on smaller deals - like the 5-site scenario above - built confidence. Technical experts who had been most resistant became advocates once they saw their knowledge encoded in the system's logic rather than replaced by it.
The metric I'm most proud of isn't on the headline list. Sales agents stopped double-checking quotes in spreadsheets after the fact. That was the real signal the platform had earned trust.
Reflection
What I learned
This was one of the most demanding and most rewarding design problems I've worked on. The combinatorial complexity of CPE quoting - multi-product, multi-site, live pricing rules, geographic restrictions - meant there was no clean solution that covered every case. What I could do was design a system that handled the most common situations well, gave experienced users room to move, and didn't break when edge cases arrived.
The behavioural and structural change aspects were harder than the UX. Designing a good workflow is one thing. Getting people to trust it enough to abandon a process they'd spent years mastering is another. The lesson I carry from this project is that adoption is a design problem - not a launch problem. It has to be built into how the product works, not bolted on afterwards.
The cross-functional team made the depth of this work possible. The BA's domain knowledge surfaced edge cases I'd never have found through research alone. The service designer kept us honest about where ACPQ sat in a larger process. The content designer's work on language - replacing jargon with how agentss actually talked - was one of the highest-leverage changes we made.
If I were doing it again, I'd push harder at the start to define explicit v1 scope boundaries. The six-month deadline meant we were making v1-versus-later calls under pressure throughout. Clearer upfront alignment would have let us make those tradeoffs more deliberately - and ship the deferred edge cases sooner.