Yesterday afternoon, I spent another full day testing an integration between an association management system (AMS) and their event registration system (ERS). Whew – we are tired! Our solution is coming together and will be great, but it’s been a very tedious project.
Why is this so hard?
It’s difficult because each system develops an architecture that supports their customer base. It does not always match other products. The small differences are typically the sticky points. With a lot of planning, a smart team, and a little patience, you will be able to develop a good solution.
A little background
The organization implemented a solid AMS and it is well designed. They also selected an ERS with solid registration technology. It sounds so simple – use one of the mixtures in the technology bag of tricks to allow customers to log in to the ERS using their AMS credentials. Why didn’t the organization simply use the AMS to manage their event? Every product has its strengths – for the size and scale of a group of events, a dedicated ERS is better.
IT was charged with developing a solution that incorporated transactions in the partner system in the AMS to support full reporting of a customer’s activity. The solution could not present any barriers to registration by adding additional effort to log in or create an account.
Developing a solution
Here are a few considerations the team should include when developing a solution:
- What problem are you trying to solve?
- Single customer record?
- Access to customer pricing from AMS from the partner system?
- Storing transactions from partner systems in AMS? What are reporting requirements?
- Learn what is available from both vendors. What is part of the API or suite of web services? What solution has the most number of happy clients?
- What is the budget and deadline for the integration?
- What is the current upgrade schedule for the AMS and vendor partner? You should build the integration on a stable, current version of the software.
- Negotiate the level of integration with the business unit. Are they willing to accept the steps required to truly integrate 2 systems?
- Outline Plan B – if you cannot implement full single sign-on, what are options to develop robust customer records with complete transactional history and reduce duplicate records?
- What is the cost of each option? This includes AMS and partner development, plus project management time, staff time, internal IT staff time, and a focus group of customers for testing.
After you have a solution sketched out, ask another round of questions:
- How does each system manage invoices? Does each line item have a corresponding payment?
- How does each system manage cancellations and returns?
- Does the association charge cancellation or transfer fees? If so, what are the business rules?
- Are customers allowed to purchase on behalf of others?
Once your investigation is complete, one solution typically emerges. The technical team must develop a detailed plan that includes workflow and wireframes that will educate the business unit. This is critical because, while this functionality is 99% behind the scenes and 1% customer facing, it is 99% frustrating for customers when it doesn’t work well.
The last step of the design process should include a step-by-step walk-through with the business owner to discuss every customer touch point to ensure the solution is complete.
Finally, the project is ready to start with development and on to testing and launch.
In summary:
- Plan
- Do (on paper and prototypes)
- Review
photo by bdesham
