酷应用

数字会展实践过程的问题反思

看点作者：31会议 2023-03-21 21:34:41

作者简介

万涛

31会议联合创始人、CEO

回到我们最开始讨论办会面临的问题，我们总结下来主要挑战是效率和体验的问题，具体来说是由这样的一些原因造成的。

一、会展实践过程给数字化的挑战

1、流程复杂

办一场小的活动就有各种琐碎事情，我是被当年我们班长拉我办活动给刺激的，几十个VIP的活动，从策划到执行很繁琐，我其实没怎么累着，班长累坏了。后来创业的时候选了这个方向，和这个经验有一点关系的。如果是一场大会大展就更不用说了，筹备期几个月，流程非常复杂，头绪太多。会前忙宣传、忙选址、忙日程、忙内容、忙演讲嘉宾等。还有那种国际化的大会，大会申办可能超过24个月，甚至要提前四、五年就开始去申办，和奥运会类似，整个大会生命周期的流程是复杂之外，还经常碰到在这几年的周期里面，人员流动变化也非常多的。

在未来AI来临的这个时代，我们做的这种专业的、高质量的、个性化的展览和服务是不可替代的。但我们看到活动的高价值同时，有时候会感觉到非常挫折，没有价值感。有时候你会觉得太辛苦了，太烦人了，我们就思考需要一款工具来提升效率。

2、形态众多

好不容易会展干到一半吧，就碰到很多关心我们的朋友来问：31能不能做赛事的数字化？能不能做节庆数字化？能不能做婚庆的数字化？这些看上去很类似，底盘的逻辑也很接近，为什么不能放在一个系统里面来完成呢？目前来看，放在一套系统里面来完成确实有挑战，C端做个人活动的有很多APP公司在做。真正专业的赛事，譬如奥运会、亚运会、世界杯这个级别的赛事，也是有专业的管理系统在支持的。当然我们也能够做一些赛事门票销售、门禁和接待相关的工作，核心的赛事流程其实还是有一些行业特征和不一样的地方。

泛Events，或者说大会展领域的数字化我们也在关注，但是我们感到一个创业小公司的力量和资源还是太有限了。我们确实也在努力满足各类用户的需求，但是也常常感到力量薄弱。

3、参与者众

我们看到的主办的核心团队也不算很多，但是他需要协调几乎所有资源都是社会化，外部的。我们简单拉一个参与者的清单就非常长，筹备期的很多工作，无论从选址、接待、车辆安排、现场搭建、物品运输、网络保障、安全问题等都是需要专业的供应商来参与。这么长的协作清单，他们什时候参与进来，做哪些事情，他的上下游分别是谁，谁来确保他的专业性和质量，他什么时候终止服务？等等这一切，在一个临时组织的巨大项目里面，都需要快速、专业、及时和准确，任何的闪失都会导致一个职能崩塌，导致巨大的风险。

我们所看到的这些问题，可能有很多的解决方案，有很多不同的专业公司也在解决各种专业问题，我们希望从一个整体的视角，从数字化视角来思考，为这些问题的解决提供我们的解决方案。当然很多方案都是综合的，并不是互相冲突和替代的，我们是彼此的方案为互补的。

关键问题是缺乏一套集成的数字化系统

随着移动互联网的发展，用户在移动端的IT技能也在快速成长，观众直接也参与进来了，从而发生了非常大的变化。由于参与者的亲身参与，用户能够自主使用大量的服务，比如注册、查询、预订、配对、更新资料、自助扫码等。由此数字化的系统不仅仅帮助组织者的效率提升，同时帮助参与者在用户体验上有很大的提升。

有问题的地方就有机会，和我们一样，有很多从事数字化的同仁也看到了这样的一个问题。于是百花齐放，大家都基于自己的理解来开发工具，去解决客户的问题。然后工具很多，相互不集成，又产生新的问题。会展中小企业比较多，基本上也缺乏有力的IT队伍来建设，市场上也缺乏完整的信息系统。

从15年、16年开始，我们看到无论在办会还是办展工具里面，就有很多人开始做数字化的工具。我们在走访客户时，听到一个信息：“万总，我觉得你们的工具也很好，另外一家工具也很好，但是我现在碰到一个问题，我这个会也不大，来的人也不多，但我用的工具五、六个，数据导来导去把我自己也导晕了，我还不如用个Excel全部搞定了方便呢。”

后来我们更近一步了解，这个会务公司也不大，但是用了一堆工具，一双手都数不过来，多到什么程度呢？网站一套、注册一套、报名、短信、邮件、现场签到一套，现场的观众注册、私域营销、酒店预订、还有内部的OA的都有很多不同的系统。关键是这些系统相互之间都是不通的，这明显是缺乏专业IT队伍带来的。

会展企业里面很缺乏IT规划的概念，此前我和我的高管团队都有IT咨询的背景，了解IT规划，罗马不是一天建成的，你必须要一步一步来做。但是如何做呢？从来没有人告诉我们该怎么做？没有手册可以参考。在会展行业，我们不仅缺乏对信息化蓝图的清晰描绘，也没有足够的资源来指导会展企业如何有规划、有步骤地开展数字化。即使有个别大型企业开展得比较好，也很少做比较深入的分享。

这里面带来很大的一个问题，一个账号切换的问题，我们主办者在不同的系统里面不断地去切换各种账号，导致效率下降。用户在切换不同的系统的时候，体验也非常不完整和不一致。因此很难有很高的满意度，主办方也无法根据用户的数据来提供洞察，并提供深度服务。一个简单的数据同步更新可能就难倒了很多人，更不用说要知道这个人的完整画像。

对比其他行业的经验，一套集成化的系统是可以解决掉刚刚提到的很多问题的，但是问题是不是大家不买，而是市场上没有这样的系统，不是需求问题，是供应问题。我们去研究Cvent的产品，就发现他们的系统的一体化程度是非常高的，在中国是没有这样的一个产品的。在办大会大展这种低频的事情里面，我们要让我们的用户去学习那么多IT工具（甚至都是一次性的），然后还需要考虑他们的集成，这个在早期市场是可以的。但是发展了一段时间之后，这个状况必须要改变。

我在17年的时候就判断这是31产品体系需要跨越的巨大鸿沟，用户有需求，但是市场上的供应不满足，市场上并没有一套完整的系统来整合他们。用户在呼唤产品化程度更高的产品，不需要有一点小问题，就依赖供应商来解决，既不方便，响应速度也不快，成本也高。难以相信在今天，还是大量存在这样的状况。用户需要更专业的产品，而不是动不动就修修补补的，专业的产品能够让他很容易在系统的帮助下达到 80 分的水平，而不是从零开始。同时这种产品系统化程度高，集成度高，能够把一套零散的工具变成一个套件的系统，需要有比较高的技术成熟度，能够实现对目前市场上的存量的零散技术能力的整合，如果能够达到这样的水准的话，估计还是有客户会买单的。

二、为会议主承办提供什么产品？

在这种情况下，我们最早在市场上喊出：31要打造一站式、全流程的会展平台。这个想法是好的，是客户喜欢的，但是实现起来非常不容易。在会展服务过程中，面对这么复杂的流程、这么多人不同的需求、这么多不同业态你从哪儿去切，你怎么做？一方面是对外提供产品和服务的挑战，另外一方面也要面临生产方式的挑战，即你如何能够高效做到这一切。几乎所有以客户为中心的企业都会面临这个问题，产需平衡。

这个问题分为外内两面，我们除面对需求侧到应用侧的压力之外，也面临着自己从应用侧到生产侧的压力，这两个压力的传导和内部能力的不足，使得技术和商业的结合过程中，产生大量的冲突。31的产品和架构历经多次变迁，都是因为我们的客户需求（商业追求）和我们的技术架构发生了矛盾，表面上看是产品和需求的不匹配，其反应到内部就是技术架构、应用架构、开发模式和人员能力的挑战。我们总结下来就是：我们是否能够从一个软件作坊进化到一个现代化的厂级流水线生产方式上？实质上是生产效率的问题，更本质上看，是人的问题。

我们要满足的需求如此复杂，如果没有更先进的架构和产品理念，是无法逃出作坊陷阱。前面也提到主办方也面临非常多的挑战，大型会展活动非常低频，用户方也不太可能经常换系统供应商，也没有兴趣做DIY爱好者，一般来讲这种情况发生在行业的早期，没有成熟的供应商，需要靠自己DIY。当一个行业发展到中后期的时候，当主流客户开始选择的时候，他们需要专业成熟的厂商，供应商能够提供更专业的服务，但是这个供应商在发展他自己的产品和服务的过程里面也并不是一帆风顺的，他真的要跨越鸿沟。

31在经历这个过程的时候，具有一定的典型性。我们做产品的时候，客户需求特别多，而每个需求都想去满足，想让每一客户满意，对产品经理来说这太难了，几乎是不可能完成的任务。所以这时候呢，为了满足各种需求，对我们自己的产品定义和生产方式提出了新的挑战。

这个挑战就是首先要定义我们要生产出什么样的产品，你的产品怎么来定义？要去满足外部多元化的需求，你内部怎么用比较低的成本去解决它，这是一个产品经理的核心问题。我这里面简单介绍一下产品经理面临的核心问题的两面，第一个方面叫外部需求怎么满足，这个一般是用户需求视角，是外部视角，是收入视角。第二个方面，内部的成本怎么去平衡，一般叫实现视角，是内部视角，是成本视角。这两个视角如果你不能够很好地平衡，最后的结果就是灾难。那很不幸我们很快就进入了灾难，这个灾难就是试图让所有人都满意，或者试图去赚所有看到的钱。

实际上我们是没有办法让所有人都满意的，也赚不到。我们当时的能力不够，不仅仅是资源，你的钱不够，更有可能是你的智力资源，或者说脑子不够，因此你是没有办法赚这些钱的，反而是你的客户不满意，会离开你，因此我们在服务我们非主航道客户的时候，就会碰到各种状况。碰到这种问题我们必须要换思路，换脑子，换整个团队的脑子。我们后来定义31的产品必须是一个平台，在平台上可以构建满足客户需求的多元化的应用，像乐高一样。这个平台不是很简单的一个系统，我们以前都没有过这样的经历。我们是不能停下来开发平台的，安安静静地等待着上线的，我们其实还是在不断服务客户的，老的系统，新的平台上的新系统都在并行。再加上疫情期间，我们又开始做线上的产品线，线上展览、直播、线上会议等，当时要做的任务是非常多的，我们也只能分个先后来做。从另外一方面，我们也得益于有了这个平台，否则我们是没有办法快速在疫情期间去开发这么多的新产品，并交付这么多的大会大展项目。刚一开始是很乱的，最终沉淀成为产品线、产品和模块的时候，我们的交付效率发生了戏剧性的变化。以前1000个w的项目，在18个月之后的交付成本下降到只有原来的十分之一左右了。这个进步的速度比摩尔定律要快非常多，因为是纯的基于互联网平台开发软件的流水线模式，能够快速迭代，每一个模块和服务都可以单独发布，并行起来的效率是非常高的。