Early takeaways from the Nethope Global Summit — What’s wrong with corporate-humanitarian tech engagement (and how to change this)
Disclaimer: Here I focus on internal working tools, rather than affected populations-facing technologies. That would require a completely different discussion, that I cannot explore here.
We often hear the trope that corporate engagement has a huge untapped potential in supporting humanitarian efforts, a sentence which is often followed by some shocked statement on how this is not happening.
The intense days of the Nethope Global Summit have shown me once more that tech companies and humanitarian actors are traveling on parallel tracks, waving at each other but struggling to get closer.
I’m not going to pretend I have the answer to this problem. A lot of ink has been spilled explaining why and how this happens, consultants have tried to build bridges, and organizations such as Nethope are actively engaging to facilitate the process.
However, a few key points stood out from these conversations and I will try to summarize them in a few points as recommendations for our perspective corporate partners. This may surprise some, as I will discard any traditional observation on how priorities diverge, IP issues are real, and communication is hard to keep flowing. Instead, I play a role where aid is usually on the receiving end: Behold to the new Giulio, Consultant on Humanitarian Marketing and Customer Engagement (pro-tempore).
HQ is NOT your target market: design with our colleagues in the field
It may sound obvious for many reasons, but it really isn’t. Very often, the toughest part is to convince wannabe corporate partner in visiting our countries of operations and do design thinking there. Somehow, this is still not seen as a priority. Well, if you are to be engaging with humanitarian organizations, you better become our local personnel’s best friend pretty quickly. There are at least two major but often overlooked points that justify this:
- Among the over 210,800 aid workers recorded in 2008 (today we’re many more), most of us are located “in the field”. Apart from cloud based systems and core organizational systems, that’s where we are more likely to be implementing new solutions. Field staff is the one that will have to use your product, that’s where your critical target audience is. As part of your product development, do some humanitarian persona design and user-centered design before proposing a solution, instead of cramming the commercial solution down our throat trying to sell it up front as exclusive tool of choice. The solutions that we use with more spontaneous enthusiasm were selected by the field and quickly adopted by others, rather than imposed from the top.
- In some — although not all — humanitarian organization, funding is received by the country or regional office through project or crisis-dedicated grants. Often, the inevitable first pilot is paid by a specific project-related grant. In this case, country\regional offices have the capacity to inscribe new tech in their budget without much noise or delay. If decided at headquarter, the same operation could or would mean an official adoption of the new tool in the institutional tech stack. While not impossible, this option requires such a cumbersome process, high-level endorsement, and bold investment to make it much less rapid, interesting and realistic.
Baseline recommendation: Approach HQ for the approval and strategic placement, but design for the field.
Craft your high-tech message to be as simple and clear as possible
Nobody is stupid, but let’s face it: Front line aid workers rarely have the time to read a full user manual, or make comparative tables by fetching relevant data from clunky and picture-heavy websites. Some of us happen to have a geeky side, spending time reading technical reviews and landscaping the tech universe in their limited spare time. All the others, mentally sounder people, they are very likely to rather rely on hearsay and inspiration from their colleagues.
This non-humanitarian related picture — to avoid any misunderstanding— is an example of a clear message that could resonate quickly: Rugged item; potential use; potential risk; why it makes the difference. It also shows that traditional marketing imagery can talk to us, the humanitarian audience.
You need another example? The second picture is quite closely related to something that humanitarians care about beyond professional duties: Reading or watching movies on an accessible, lightweight, sturdy, battery-friendly device. Extra bonus: You stop sacrificing one of your suitcases for books, and falling asleep on top of your laptop. Extra extra bonus, explain also how your technology is not contributing to existing conflicts.
No need to reinvent the wheel or add charity or ‘beneficiaries’-related messaging. Actually, please don’t add that at all if you can, unless you have a very strong humanitarian communicator in the team.
Just take the time to understand who are you talking to, and what they need. Ring a bell? It’s user-centered design, the methodology that humanitarians are considered to be ignorant about. Granted, this is much easier for hardware products, especially if they perform a specific function. As one brilliant speaker at the Nethope Summit put it, “the cloud isn’t as sexy in picture”. But hey, isn’t it this kind of things why we need creative professionals to help us with the comms and marketing?
PS: Something less ‘macho tech’ works quite well, too. And don’t feel obliged to use gray or black as in the first pic. We like colors a lot, actually.
Prepare tactical teams ready for deployment
Humanitarians, especially those dealing with armed conflict, work — wait for it — in zones of violence. Annoying as it is for the corporate insurance providers, that’s the hard truth. This also involves that some companies willing to help are not in condition to do so because their team meets obstacle in deploying quickly (or at all) into a country of operation. Things get even trickier if embargoes and sanctions are involved.
Recruit former humanitarians or veterans to do the groundwork, negotiate more flexible agreements with your insurer, and make sure your aid-facing staff obtain security clearance way before traveling. Humanitarians are usually in a rush to deliver. It takes us an excruciatingly long time to set up the governance and financing requirements needed to start a pilot, but when it happens we have to deliver swiftly and effectively. First and foremost this is a matter of humanitarian imperative and respect to affected populations, but also administrative reasons play some role: The funding time frame imposed by donors is often quite tight and all funds unused are lost (yes, that’s also why sometimes pilots have no ‘commercial follow-up’).
Build your licensing model on impact, remove entry caps
Differently from the corporate sector, humanitarian organizations are rarely able to determine how many staff members will be using a specific tool. First of all, aid workers tend to have a genetically looser relationship with corporate decision making: The simple fact that a solution has been bought by HQ and is available will rank quite low in the list of reasons why we could actually use it.
Secondly, as already explained above, every single context is different and it’s almost impossible to predict what will be the perfect solution for everyone during the time span of a license. Adoption in a given time could be influenced by workload, staffing, priorities, holidays, office schedule, motivation, needs, or even conflicting solutions being piloted. At the same time, a tool that is not picked up by an office today, could become the default solution of choice tomorrow. By imposing us entry fees, you are basically closing the doors to potential and unexpected mass adoption in the future.
All in all, your tool’s best bet is to convince us that it can make our work (and impact) better. Once this happens, we will individually, locally, regionally, carve out the budget needed to unlock additional features. At that point, the chances of a snowballing effect bringing adoption to critical mass scale are very real and the gate to our tech stack is wide open: Bingo!
Baseline recommendation: Design pricing based on incremental adoption, not on upfront mass buy in.
Last, but not least:
When you say that you want to adapt the solution to low-connectivity locations “such as Africa”, we go blank. You lose us completely. It’s the equivalent of a humanitarian walking up to a corporate engineer and saying “I have an idea for a new App!” It’s a downer, it just puts us on stand by mode.
That’s all from me, I guess.
Oh wait, I almost forgot: No need to pay now, I’ll send my invoice.
