So, your client wants a portal?
Maybe you’re working with a client who has some percolating ideas. Maybe you’re trying to pitch a client on a tool you think will be valuable for them. Maybe you’re in the midst of a portal build now and want some advice.
This case study goes beyond general, introductory tips for portal builds.
Instead, it shows the practical side of managing a portal build, factoring in team and client attitudes, budgets, unexpected discoveries in QA, etc.
Here’s your chance to learn how to plan your approach, avoid the same mistakes we made, learn from our takeaways, and build a portal like a pro.
A Bit Of Background
We’ve been extremely lucky at our agency to work on some unique projects with exciting, high-profile clients.
One of our most notable projects recently was a portal project with a prominent electronics retailer that involved a digital transformation of their B2B shopping and order management process.
Our client provides special pricing and discounts to businesses who order large volumes of products. When we started the project, our client was managing orders through a manual offline process with their account managers. This created issues for both the business’ customers and the client’s team by creating excess work and processes that could otherwise be offloaded to an automated management system.
Steps We Took In Managing A Portal Build
1. Determining The Client’s Needs
We worked together with our client’s product owner to determine the requirements for an online portal where their customers could sign on and shop from a catalog of products curated and priced specially for them. In addition to the business customers and their online shopping experience, we needed a user role for our client and their account managers to apply catalogs and pricing to the business customers, and download and process orders as they come in.
In addition to the portal ordering and pricing logic, we had some interesting requirements that apply to a B2B E-commerce portal.
- Personalized dashboard
- Personalized offers and promotions
- Shopping cart and checkout
- Bulk, repeat and scheduled ordering for regular customers
- Multiple users to enable different departments to purchase products for their needs
- Order management tools for account managers to address specific orders
It seemed pretty cut and dry. We knew what was needed, we were aware of relevant examples from competitors, and we had the team to get it done.
A few wrenches were thrown in along the way.
2. Forming A Plan Of Attack
When we kicked off this project we went in with a whiteboard and a dream. To be honest, we massively underestimated some of the mandatory features of the project, but I think that’s what made the project fun.
Our client requirements seemed overall pretty basic, they wanted 3 different user levels:
- Admins for our client, who can manage clients, their products, the discounts, and the orders coming in.
- Client admins, who can review and add new users for their organizations, as well as placing orders.
- And client users, who can shop and place orders from a catalog tailored to them.
We were leveraging an API that allowed us access to all of the different products our clients sold through their website. We then put on some pretty tricky logic on top, to allow users to only view products assigned to them, and then apply a tailored discount on top per client.
3. Executing The Portal Build
This project was executed in a hybrid agile approach to development and design. We did an internal kick-off for our UX team starting a sprint ahead of dev to flesh out some of the main features and requirements. In parallel, our dev team helped with solutioning and environment set up.
We were lucky to have a dedicated product owner on our client’s side who was present for every sprint planning meeting, provided feedback to UX at mid sprint reviews, and accepted our features as complete in our sprint demos at the end of our two-week sprint cycles. He was really engaged and hands on and didn’t hold up the process. He was quick to bring appropriate stakeholders into sprint demos for particular features they might have an interest in. He trusted our process and valued our opinions. He was really a gold star example of the dream client.
We kicked off the project with a three-week discovery phase to define requirements, sort out technical problems with their API team, and project plan. We aggressively planned for five, two-week sprints, included a contingency sprint for cleanup that took place over the holidays, and a month-long QA/UAT process.
More or less, the project went according to plan. Our client dreamt up some new features and tasks along the way. Some took as much as an entire sprint to complete. The budget increased, but our timeline did not. There wasn’t much flex to support this and our contingency sprint was eaten up quickly.
Our process and team’s commitment to the project was stellar. We were lucky to use some interesting tech that kept the team interested and engaged. We didn’t have a sandbox to play in, we had a beach.
We kept an extremely lean team on this project really helped what we could accomplish. It seems counterintuitive, but we were able to get more done, with less people, distractions, opinions, and changes. Our team all worked together throughout, solutioned every feature together, thought of things critically, and presented the options to the client. Less noise meant we were able to keep a streamlined process and keep the scope of each feature manageable.
Our backlog was robust, and still continues to be today. We regularly deploy new features to the portal in scheduled releases. If something wouldn’t work for our MVP, we parked it, and tackled it later. Our client was good at agreeing to what needed to be there to function.
The best thing to come out of this project is the refinement it had on our project process throughout our agency. We helped define how we work on projects of this scale with all the teams in our organization. We’ve worked with other project teams to roll this out on other projects to better our efficiency, client engagement, and project success.
We succeeded in completing stories, adapting quickly to some last-minute client requests, and overall, developing a portal we’re super jazzed about. Our client too!
Make it work. Make it right. Make it fast.
We initially did not succeed in site performance. This portal has so many complex integration points, which themselves have a massive load, and once we put on our product assignment/discount logic on top some of the shop and add to cart pages took minutes to crawl to the screen.
Our client coined our loading icon the “spinning wheel of death”. Definitely kept our egos in check after we were so pleased with our delivery!
We rectified this by creating our own product cache, of 60,000+ SKUs on our server, which is updated every 48 hours to check for price, and other relevant information that might need to be frequently captured on the shop and product pages.
Looking back, our QA process needed a bit of love. We didn’t have appropriate test cases and the acceptance criteria was lacking. This didn’t help when we needed to parachute a new QA team in, and they needed to get ramped up on the project. It definitely slowed down the process and was a visible pain point on our client’s side.
Post project we executed two project retrospectives. One internally, and one with the client. Our team really went into the nitty gritty and reflected back on the project and how we could improve. We were critical of ourselves, without posting blame, we knew where we could make strides and were excited about the learnings we had from the process.
Our client retrospective went much differently, they brought up QA as a pain point, and them spent time addressing what worked in the process, and what they liked about working with us. Classic.
What We’d Do Differently
Next time we’d be a bit pushier on our timeline. We really wanted to “wow” this client and make a good impression because we’re hoping for a long-standing relationship with them. We’ve definitely built up trust and understanding over the past year working with them, they look to us to guide timelines and inform them of what we can commit to.
Moving forward, on a project like this we’d like to quote on a cost per sprint model. This can be tricky with new clients, especially when they might not have a full understanding of the build and duration of the project. We’d need to come to a happy medium, as we definitely took a hit on what time and resources our agency invested in completing this.
Overall, we learned a lot. Our team is thrilled with the product we put out. Our client values our opinion as the subject matter experts. We’ve continued to iterate and make the portal better, and we’re actively working on planning for a large phase two that will bring new features and a large user base to the portal.
Takeaways For Managing A Portal Build
- Manage your timeline Even if your team thinks it’s a cakewalk, add a contingency sprint or two.
- Keep the team lean. Fewer cooks in the kitchen keeps things on track and everyone aligned to the same vision.
- Treat your client as an extension of your team. Embrace their collaboration with open arms. They can make your life easier!
- Define your test cases early. Consider how each are impacted by different user roles.
- Honor your sprint ceremonies. Evolve your process, and always keep your finger on the pulse.
- Keep your team engaged, and your client involved. Shed processes you don’t need but embrace the ones you do.