Here we are, the final SECTION of the year.  A period we SECTION off for some well-deserved time off doing the things we love most.  That’s what I’m all about, right?  Giving people back more time so that they spend it doing things that make them happier?

Well, I couldn’t say I’m all about consulting if I didn’t toss out a framework with acronyms that spell common words and cover essential topics occasionally.  With that, I introduce to you the SECTION Framework for Interactional Functional Requirements gathering ™.  The goal of this framework is to improve the outcomes of interactional automation projects by adequately cataloguing and juxtaposing requirements from different facets.

If you’ve successfully automated complex interactional solutions with many integration points and data types, you may already have a similar or related approach to ensuring you mitigate risks and exploit benefits as early as possible.  Great!  If you haven’t, this is the first of many blog posts where I aim to help you make informed decisions more quickly when ideating, designing, delivering, or optimizing customer experience or interactional solutions.  I refer to the types of solutions I describe here as interactional solutions because that is really what they are.  Through most of my work has been focused on the contact centre, these can easily be HR and IT solutions, or other types of general productivity or lifestyle solutions. Whether you are looking to insource or outsource the execution of your initiatives, the quality and comprehensiveness of your requirements gathering will greatly affect the accuracy of forecasted timelines and budgets and the final quality of the work.

The SECTION Framework separates interactional journeys into seven distinct SECTIONs.  You can populate the SECTION framework as an individual if you think you have all the answers.  Still, I highly recommend doing this as a team workshop and leveraging data and design thinking games to get everyone engaged and the encourage the broadest input of ideas and feedback.  Here is a brief image of a populated Miro board template for the SECTION framework; more details to follow.

Each row on the board represents one of the seven SECTION facets, and each column represents individual sequences that make up the journey.  Here is the framework defined in brief.

SECTION	Description
Sequence	One or more steps that group into an important milestone in progressing the journey.
Entities	The “things” you need to work with or talk about can dramatically impact the cost and timelines of automating interactions.
Costs	The average costs of completing this sequence.
Timelines	The average/estimated length of time to complete the sequence.
Integrations	The systems or channels that connect this journey to customers, employees, and line of business systems.
Outcomes	The final end-states from executing the journey.  These should include all positive and negative outcomes.
Notes	The questions or noteworthy considerations that require further action or discussion.

One of the key benefits of this framework is that visualizing these requirements together (especially as a team!) helps you more quickly identify gaps and validate that your requirements are mutually exclusive and comprehensively exhausted (MECE) [1].

Let’s use a real-world example for a project I’m working on to showcase my work: a voice-based assistant to answer my calls when I’m in a scheduled meeting and schedule a follow-up as soon as possible and convenient for the caller.  This project isn’t about cost savings, but it will keep me focused on scheduled work and avoid the communication channel switching and follow-up to set up a time to connect.

In this case, I have a reasonable idea of the functional requirements of this use case…  but what if I didn’t?  What if I don’t know what I don’t know?  I’m a big believer that you should always start every project with discovery. Let’s go with a mix of my assumptions around process and flow, and use some generative AI/large language models (LLMs), natural language process (NLP), and machine learning (ML) clustering algorithms and a Python notebook to get some additional help ideating and completing the framework SECTIONs.

Let’s start by digging into the first SECTION.

SECTION #1 – Sequences

The Sequence SECTION represents the main milestones or progression steps toward completing the journey.  The easier way to think about the underlying representation of the progression through sequences as a flow chart for a business or technical process.  The above example is mostly linear, and you can see the transition pathways from one Sequence to the next with arrows, but that may not always be the case.  I’ve always enjoyed thinking about business process the same way I think about software architecture, especially in the context of Domain Driven Design and bounded context [2].  With regards to Sequences, you could in theory have a complex unified Sequence that handles an immense amount of loosely related tasks as a single process model.  That would be impossible to visualize with the SECTION framework.  There are pros and cons to large coherent monolith process models, but one key benefit of having smaller loosely coupled processes that always win for me are: a) the ability to look up a process years later and make sense of it quickly, and b) the ability to experiment and iterate on pieces of a process quickly and independently.  My advice, if you can’t fit your process into a framework like SECTION without the board having 100 columns for Sequence progressions, consider splitting apart processes and even adopting more of an event-driven approach to business processes.

Once you have your process mapped out into reasonable enough number of steps for you to visualize (it’s entirely subjective, as long as everyone can make sense of it!), we can move on to the next SECTION.  Each subsequent SECTION will be anchored in context by the Sequence SECTION at the very top.

SECTION #2 – Entities

The Entities SECTION is where you define the type of things and important data structures you will work with during the journey.  The Entities should include things that will be exchanged in interactions, as well as things like database entity records with key information.  It should also include indicators to mark these data points as Personal Identifiable Information (PII) or payment details (credit card, and others). This SECTION is one that will influence the complexity of implementing the interactional aspects of the journey.  If all you need to do is confirm or disconfirm a decision, your solution will be quite simple.  If you need to understand people names and street addresses over speech channels, there is much more complexity in backend processing and systems necessary to discuss those effectively.

Beyond identifying those gotcha use cases based on entity types, setting aside time to ideate and catalogue possible entity types, is very valuable.  We don’t know what we don’t know, so asking lots of people to rapidly share ideas in a time-constrained manner can be very beneficial.  If you don’t have tools to facilitate larger scale collaboration in meetings today, I highly recommend Slido [3], which I grew very fond of during my time working for Cisco Systems (the makers of Slido).

Still, ideating is great, but it’s better if we can inform ourselves through data.  But where is that data?  Who has it?  How do we get access to it?  How would we analyze it if we had access to it?

Figuring out where to begin is hard if it’s not something you’ve done repeatedly.  For the past couple of decades, speak to any business about trying to get accurate reporting information from their contact centre, and you’ll usually get mixture of awkward faces, laughs, or the most common one “Yeah, we know we need to do more with reporting!”.  It was a rare treat discussing contact centre automation with someone who had a Workforce Optimization (WFO) solution and had recordings, transcripts, and intent analytics.  Those systems weren’t perfect, but they helped a lot more than depending on contact centre disposition codes for reporting reasons for contact.  The biggest reason more people didn’t have them?  Cost.  As someone who knew first hand the benefits offered by WFO solutions, I don’t believe the cost is high, but convincing someone who hasn’t needed it to date is another story.

Well, that’s one of the great things about the pace of innovation and the availability of SaaS platforms today to help create a lot of the backend processing you need to start extracting insights from your data with minimal upfront infrastructure investment.  For the sake of brevity, in this blog post I won’t get into call recording transcription, but that will be a topic of the future, as there are so many great options available, some with built in data loss prevention, speaker diarization, and other features.

The main focus of extracting insights from data in this SECTION blog post will be identifying probable and possible interactional Intents (ways people will say things) and Entities (things people will reference in the things that they say).  I’ve published a GitHub project [4] with a Python Jupyter notebook that will walk you through leveraging generative AI to simulate agent transcripts for my assisted scheduling use case and use LLMs, ML, and NLP to extract these details to feed into the Entities SECTION.  You can check out the notebook in a browser directly here. The code produces two main outputs for the Entities section. The first is named utterance groups and their distributions, identified by semantic similarity clustering.

The second is identifying commonly recognizable named entities, which you can also customize as you learn new custom types for your interactional domains of discourse.

Note that the clustering and entity recognition is done on data on all participants and every turn of the conversation. You want to know everything people are saying with ideating on requirements. There is value in separating participants and turns when analyzing data with these tools, such as identifying emergent utterance responses to the age old question: “How may I help you?”.

Despite having immense confidence that I had captured everything, through these efforts, the data exploration showed me that I hadn’t thought about time zones, people confirming emails over the phone, period of day (morning, afternoon, evening) references, and more!  Even though generated transcripts do not reflect the exact reality of your use cases and users, think of using generative AI to simulate data and using tools to analyze the results as having another team member contributing ideas to consider, accept, or reject.

The GitHub project documents its usage within the README.md and notebook, so I won’t cover that here.  Besides, you might already have commercial tools that accomplish the same thing, and you’ve already completed the Entities SECTION and are ready to move onto the next.

You might be wondering why I’m not capturing Intents in this framework.  Often in production, there can be several hundred intents that make up the phrasings the solution will understand.  Many of these are also context specific to the sequence or turn you’re trying to complete.  Dialog management is, in my opinion, the least documented or mature area within the conversational AI sphere of required capabilities, despite being at the core of delivering successful experiences.  That’s an area I plan to cover more exhaustively on its own in the new year.  Especially now with the ability to deploy hybrid NLU and LLMs solutions, Intents are a very interesting subject.  For today, I’ve used the Intents information to inform me more of entities than phrasings. For example, there was no detected entity for time zone, but there was an intent cluster identified that grouped together utterances providing time zones. Any way let’s move on.

SECTION #3 – Costs

The Costs section is very straightforward.  The idea here isn’t to identify the exact costs, but to itemize the costs that will or already exist.  Note that this should not include the cost to develop or work on the solution.  Everything we collect here is to either predict future costs, or identify the costs that need to be baselined before to make changes to that we can measure improvement.

In the above example, most of my costs are related to SaaS-based infrastructure for telephony, cloud infrastructure, analytics, and a calendaring API service.

When you’ve completed this section, you can move onto defining the costs in the format your organization expects today.  For myself, when it comes down to defining actual costs, Excel is often a better friend than any other tool for creating custom calculators to represent costs adequately and easily distribute as a shared document or by email.  The trio I like using to represent each component that incurs cost is: Up-front (Fixed), Recurring (Fixed), and Usage-based (Variable).  Make sure you look at each component and define each comprehensively and produce an estimated total cost of ownership (TCO) for three to five years.

Onto the next SECTION.

SECTION #4 – Timelines

The Timelines SECTION is easy to comprehend but can sometimes be more challenging to complete depending on the nature of the Sequence at hand.

Mapping my telephone scheduling assistant was relatively simple.  No Sequence exists without doing something important, and anything like API lookup involving a cache, I set to < 100ms, I used my best guess for how long it might take someone to talk through the Check/Align Availability and Get Follow-up Preferences Sequences, but if you have time and access to subject matter experts in your project, interview them, measure the process if you can – get the data, but know that you might have to estimate it, and use that as a baseline to start.  I highly recommend t-shirt sizing as a team if you need to estimate efforts. Worst case scenario, if you need to estimate data that could result in critical success or failure of your initiative, that should be immediately documented as a High Risk for your project, which should put it front and centre to address, likely by having a senior stakeholder accept the risk, offer their own estimate, or authorize doing to work to accurately measure and baseline the average behaviour.

You can’t improve what you can’t measure!

SECTION #5 – Integrations

No interactional solution exists without the bare minimum of either a single system or channel integration.  Here I define system as a line of business system, and channel as a service interaction channel, like a web page UI, telephone call, SMS, Email, and more.  If specific devices or modalities require custom integration beyond servicing the default channel itself, include them here also as another type of or extension of channel integrations. Without connections to outside things, there would be no inputs to generate outputs.  The tree would fall in the forest and the solution wouldn’t be informed, and you’d never have that log message! (pun intended…)

For brevity, I didn’t expand this section as much as I would recommend doing for adequately defining a scope of work for projects.  Beyond simply listing things like “Calendar API”, you should itemize the individual API requests that will be necessary.  Each of them could communicate with a unique endpoint, has unique parameters, responses, and add to effort estimation.  Every integration will incrementally add to estimated efforts.

Take special note of channel integrations.  Depending on the systems you are using today, adding a channel may have a multiple or a negligible effect on timelines.  This is one of the great values in adoption a Communications Platform as-a Service (CPaaS) solution that supports a wide range of channels.  A common middleware/aggregation point of similar channels can significantly reduce time-to-market in extending solutions to new channels.  Think about the channels you want on day 1, and in the next 1-2 years.  If you plan on expanding channels during that time, it’s best to look at CPaaS channel aggregation systems at the onset.

SECTION #6 – Outcomes

How does this journey end?  What does success mean?  What could go wrong and preclude things from succeeding?  The Outcomes SECTION declares the positive, negative, or neutral end states.

Conducting a pre-mortem workshop with stakeholders representing all components involved will reveal an incredible amount of information around what could go wrong.  In the book Design Sprint – A Practical Guidebook for Building Great Digital Products [5],  the authors refer to conducting a pre-mortem with an aim of imagining all the reasons the design sprint could fail (identifying risks), and ensuring a fix is in place ahead of encountering the problem.  That’s exactly what we want to identify here, but instead of focused on a design sprint, we focus on the journey.  Get everyone together and start with “Imagine this step has failed.  What are all the possible reasons?”.  It’s a lot easier to make a fun exercise out of specifically asking for people to envision that everything catastrophically failed and contribute as many reasons as to how collaboratively than it is to ask teams “What could go wrong?” and deal with people not wanting to point fingers at others or feel like they’re disclosing things they think might reflect poorly on them (it shouldn’t ever, anyway).

Sometimes when we look at outcomes as “pass” or “fail”, we lose the perspective of the person using the solution and what they might be experiencing.  A good design thinking game to go a little deeper into what happens “after” a positive or negative outcome is the Empathy Map game which I first learned from the book, Game storming [6]. Sometimes spending the right time empathizing could change a perceived low risk to a high one.

You can even ask ChatGPT to give its opinion if it wouldn’t involve disclosing private information or intellectual property.

Every undesired outcome should contribute to the roadmap to making the solution more bullet proof.  These should be input into a risk management framework to ensure you eliminate risk as early as possible or fail quickly.

The positive outcomes should drive the ultimate goals of the sequences that will be created in the solutions themselves.  If you know what you’re trying to achieve, you can craft much better interactional experiences by steering the conversation towards desired outcomes as promptly and cooperatively as possible.

SECTION #7 – Notes

The final SECTION, Notes, captures the outstanding questions and feedback for things that require follow-up before the SECTION framework can be considered complete and fully populated.  Be open-ended with this section.  It’s better to use it in a quick manner than to ensure everything is phrased as a question, or in some specific format.  Capture thoughts that require follow-up as you encounter them, and ensure you action them toward completing the remaining SECTIONs.

End of SECTION… or is it?

Well, we’ve run out of acronym letters to explain.  The framework is complete.  But wait… is it?  I’ve completely ignored a couple of very important contexts for any interactional solution: Localization and Regional Availability!

In cases where you are working with a single language and region, the SECTION framework will work as it is.  When you need to support multiple regions and languages, the SECTIONAL framework ™ has you covered.  The two additional rows represent (A)vailability of the service, and the (L)ocales required.  I use localizations instead of language because many individual languages have very different localized variations of expression.

Sit back and relax on your SECTIONAL while I cover the final two letters of this ever-growing acronym.

SECTION #8 – Availability

The Availability SECTION defines both the presence of and access to the service.  In this context I refer to Presence as the physical deployment of resources made available to provide the services, and Access as the width of the scope of intra- or inter-regional availability.

Using the above example, my voice assistant will have a Canadian phone number.  I’m claiming my physical presence for receiving phone calls is in Canada, but in truth I believe there is likely some US infrastructure in the way I plan to connect calls from Canadian PSTN into my assistant.  Adding additional points of presence (POPs) may or may not have a significant impact on effort estimation based on the nature of the infrastructure required.  Some SaaS services enable seamless expansion into new regions with a few clicks.

While my phone number is connected in Canada, does that stop someone on an ocean cruise using a satellite phone from calling?  Not at all.  What about all those spam calls from weird numbers? Yeah those can contact you also. Should you be concerned about these things?  Well, actually, yes!  I spent years being responsible for telecommunications fraud and cyber-security for a service provider and let me tell you, the entire world is always poking at you trying to identify vulnerabilities and exploit them, 24/7/365.  If you know without a doubt that you will only offer business in certain regions of the world, close access to your services to everywhere else.   You could substantially reduce the surface area people can use to perform reconnaissance or launch an attack.  It’s not just about cyber-security.  Many communication and bot services involve some form of usage-based billing.  Why bother paying for someone who can’t use your services to contact you?  There are obviously legitimate reasons to expand beyond your target serving area.  Imagine you are a bank.  You want someone traveling abroad who lost their phone and wallet to contact you to disable their cards.  Aim for the highest degree of lockdown possible without inconveniencing the people who need to interact with your solution.

After cataloguing the Availability of the journey, ensure you are fully compliant with laws and regulations in the regions you house or make your solution accessible.

SECTION #9 – Locales

Does your name mean something offensive in another language?  Maybe!  Could it even be offensive in your own language somewhere else in the world?  Yes, definitely!  Imagine if your business name means something taboo in a new market where you want to launch?  Some cultures place significance in the use of numbers – what if you publish a phone number or price that contains numbers that are associated with bad outcomes?  All these scenarios are very real and succeeding in certain markets depends on understanding and customizing your services to existing and different expectations.

Closing Thoughts

Well, that’s it, the entire SECTION(AL) framework.  I know I misled you in the first SECTION, but here it is in all its glory.

Here is the full SECTIONAL framework defined in brief.

SECTION	Description
Sequence	One or more steps that group into an important milestone in progressing the journey.
Entities	The “things” you need to work with or talk about can dramatically impact the cost and timelines of automating interactions.
Costs	The average costs of completing this sequence.
Timelines	The average/estimated length of time to complete the sequence.
Integrations	The systems or channels that connect this journey to customers, employees, and line of business systems.
Outcomes	The final end-states from executing the journey.  These should include all positive and negative outcomes.
Notes	The questions or noteworthy considerations that require further action or discussion.
Availability	The presence and access to the functionality provided by the journey.
Locales	The localized languages and accessibility implementations for the journey.

Was that a lot?  Oh yeah, it was 9 whole letters!  I’ve won at consulting framework Countdown [7].  As much as I like to joke, I do hope this framework and the code notebook on GitHub [4] will be useful to you and others in collecting and reflecting on interactional solution requirements, so that you can make or facilitate more informed decisions in providing better experiences to people.  If we can automate the stuff that provides the highest impact, we can say we’ve maximized the return on lifetime investment (ROLI? 😉 ) for people while reducing cost to the business (ROI) through increasing customer capacity availability or reduction of staff allocated to those activities.

If I can help you give your customers, team members, or anyone else more time back through delivering effective automation interactional or not, then I’m achieving my goal at scale.

Don’t be shy, connect, reach out, and say hello! Schedule a meeting or write to me at justin@sitinc.net and let me know if or how this framework or Python notebook helped you define better requirements and resulting outcomes.

References

[1]	Wikipedia, “MECE principle,” Wikipedia, [Online]. Available: https://en.wikipedia.org/wiki/MECE_principle. [Accessed 23 12 2023].
[2]	E. Evans, Domain Driven Design, Boston, MA: Addison-Wesley, 2004.
[3]	Cisco Systems, “Slido – Audience Interaction Made Easy,” Cisco Systems, [Online]. Available: https://www.slido.com/. [Accessed 23 12 2023].
[4]	J. Randall, “sitinc/journey-discovery-getting-started | Python notebook and modules to explore customer journey data.,” Smart Interactive Transformations Inc., [Online]. Available: https://github.com/sitinc/journey-discovery-getting-started. [Accessed 23 12 2023].
[5]	C. T. L. T. W. Richard Banfield, Design Sprint – A Practical Guidebook for Building Great Digital Products, Sebastopol, CA: O’Reilly, 2015.
[6]	S. B. J. M. Dave Gray, Game storming, Sebastopol, CA: O’Reilly, 2010.
[7]	Wikipedia, “Countdown (game show),” [Online]. Available: https://en.wikipedia.org/wiki/Countdown_(game_show). [Accessed 23 12 2023].