搜索:   
现在的位置:首页 > 网站运营

运营部分机闭怎样搭修

来源:本站 作者: 发布时间:2020-05-19 05:12:17 人气: [ ] 查看评论

收藏到网摘: 新浪ViVi 365Key网摘 天极网摘 我摘 POCO网摘 和讯网摘 博拉网 天下图摘 Google书签 Del.icio.us Yahoo书签 DIGG this story 添加到百度搜藏 将本文在板儿砖上开砖场

  本文介绍了运营体系的框架搭建、B端产品的运营体系的区别、强调了数据运营的重要性、分析了运营智能的划分和组织结构的选择,与大家分享!

  运营因为其涵盖的范围非常宽泛,记得刚接触运营的时候□□,就像是刘姥姥进了大观园□□,感觉什么工作都和运营相关。

  但真正实质的工作又像是打杂的□□□,天天就是内容排个版,网上发个帖子、做个推广等等。

  这是由运营工作本身的实质决定的□□□□,我们先来看什么叫运营□□□□,运营就是对过程的计划、组织、实施和控制,是过程中密切相关的各项管理工作的总称□□,所以运营的工作繁杂必然是在所难免。

  因此运营在一家公司具体落地的时候□□□,作为企业的运营负责人,必须要有一套运营体系来把运营的工作进行串联协同□□,否则就会造成很多环节的浪费。

  事实上这种现象在一些公司非常普遍,一般这种情况下,老板会自带运营,然后有几个专长的运营经理来负责□□□,比如推广等。但是在运营的其他环节如果没有形成体系,就会造成资源的浪费是必然的。

  运营作为公司这个商业组织,所有商业行为的管理工作□□,他的核心目标就是通过外部市场的拓展、内部效率的优化,达到企业发展的目标。

  事实上□□□,任何一个商业组织□□□□,只要已经实现稳定盈利,那么就必然存在着一套运营体系。

  因为商业利润不会凭空产生,它是运营体系运转的结果。而在互联网行业□□□,与传统行业侧重点又会有不同。

  但从大的角度我们都可以用漏斗模型来看待整个过程,包括获取客户、客户转化、客户服务三个环节。而在这三个环节中我们又可以总结为三个关键点:关键行为界定和产品力、运营策略、增长策略。

  一个完全没用或不能用的产品,如果还非要强行推给用户□□□□,那就是在耍流氓。但是从运营的视角上看,不能如同产品细化到价值体验层面,而是用数据化的方式去呈现产品力。这个数据的内容就是用户关键行为。

  在用户成长历程中,这个行为的发生是用户成长的转折点□□,它的发生率往往代表着用户对这一产品的认可度,也在一定程度上决定了产品价值。

  应该注意的是:这一关键行为的发生不一定等同于KPI,而是对KPI的完成影响较大的一个或两个因素。比如说:GMV是电商平台最关心的KPI指标,而GMV和用户的订单数以及订单金额高度相关,那么□□□,用户下单就可以作为最关键的用户行为。

  当通过各种运营手段,为产品拉来了用户后□□□,我们如何对这些用户进行引导,确保关键行为的发生□□,并促使他们深度体验我们的产品价值。这正是用户运营策略要解决的问题。

  用户运营策略是运营体系中最为核心的环节。如果没有一个稳定可靠的用户运营策略,那么增长策略的制定便没有意义□□□□,用户关键行为的发生更是无从谈起。

  当我们界定出用户关键行为后□□,我们就要在新手引导流程上,确保这一行为发生的几率。

  比如说:某网站界定出的用户关键行为是注册□□□,那么,一个比较合理的用户引导设计就是:当用户首次访问网站时,弹出一个新人大礼包,用户点击领取后,需要完成注册□□,以此来增加用户关键行为发生的几率。

  当然,用户关键行为的发生,有时候并不能只依靠新手引导,很多时候新手引导的设计只是让用户完成某些动作,而这些动作的完成将有利于关键行为的发生。

  比如:知乎、微博等社区在新用户完成注册后,都会去引导他们去关注其他优质回答者,或者向用户推荐一些优质内容;因为只有这样,用户才有可能在后续的成长体系中发表自己的第一条状态。

  用户成长体系的目标是:让用户自愿去完成我们的预设动作□□,这个动作可能是关键行为的发生,也可能是深度体验我们的产品□□,引导其成长为粉丝用户。

  应该注意的是:并不是所有的产品都需要用户成长体系,对于一些需求极其强烈的产品。比如微信、12306等,我们不需要刻意去搭建一套成长体系去激励用户。

  适合构建用户成长体系的产品更多的是一些高频的,但需求没那么强烈,则可以通过搭建用户成长体系加强用户的粘性。

  一般用户成长体系的构建都采取游戏化的设计□□□□,即让用户完成一些任务,并相应地给用户一些激励。这些任务一般包括三个方面:新手任务、常规任务和非常规任务。

  而关于用户激励□□□,最为常见的则是给那些完成某些任务的用户,发放可以在平台内流通的虚拟货币或优惠券。

  明确以上两点后□□□,我们就能清楚□□□□,流失用户召回的关键就是要建立一套用户流失预警机制。

  这套预警机制建立的前提是用户流失模型□□□,用户流失模型中最重要的一点就是:要明确用户在流失前会呈现哪些特征。比如如用户访问频率从之前的一天两次,降低到两天一次□□□□,以及分析呈现出这些特征的原因是什么。

  清楚了这些□□□□,我们就可以在用户呈现出这些特征后,运用各种运营手段对这些用户进行特殊关照,尽可能的挽回他们。

  增长策略解决的是流量获取的问题,再完美的运营体系也只有在持续的流量获取的基础上□□,才可以运转下去。

  并且在一款相对成熟的互联网产品的运营中,增长策略不会只有一个,而是付费增长策略和免费增长策略多轨并行相互交叉,只有这样才可以使整个运营体系在快速运转中,不断变得更加高效和成熟稳定。

  产品自增长策略是指融入到产品内部设计当中的增长策略,这种增长策略的执行□□□,基本不需要人工参与。

  我们可以理解为这种增长策略是用户自发进行的,更多是和产品本身的口碑密切相关。

  例如很多产品的都有的“老带新”策略:鼓励用户去向他的朋友推荐该产品,如果有朋友通过他的推荐,使用该产品□□,那么用户和他的朋友都会得到一定的奖励。

  这些其实就是产品化的增长策略,这种策略的效果和产品本身的价值和口碑密切相关。如果能够应用得当,尤其在现在信息泛滥的时代,人际间的传播可信度极强□□□,会带来意想不到的效果。

  因为参与自增长的用户一定存在一个二八定律,所以如果产品质量或受众受限的情况下□□,自增长的的用户是会迅速衰减的。这时候就要增加渠道增长策略不断的去获取外部的流量。

  这也就是运营人员一般工作最多的部分,就是通过各种手段去外部获取流量。这一方面可以提升产品的知名度□□,另一方面也可以维持产品本身的新陈代谢。这种手段一般包括各种增长活动、渠道投放和营销事件策划等等。这种策略的执行□□□□,往往就需要运营人员深度参与其中了。

  以上就是运营体系的一个基础框架□□□□,但是偏C端的□□,如果面向B端的类的产品运营会相比起来有一些区别。

  相比随机性较强的个人C端用户,B端运营服务的主体则是一家企业。企业的决策都是理性而现实的,而且还存在一个组织协同的问题。

  所以B端客户一方面就要把产品运营流程化到人到人的服务,就是把B端转化成C端,用人来服务于人,从而达到决策使用的目的;另外就是建立以客户为中心的经营体系。

  要达到人服务人的目的,并满足B端客户的要求□□□□,需要建立这三块的标准化流程□□□□,保障服务。包括:建立运营流程、产品培训标准、产品优化闭环。

  杂乱无序的B端运营工作,必须从中理出一些思绪去考虑搭建一些框架出来,让无序的工作变得有序□□□□,必然要把工作规范化、制度化;有了制度避免各部门间的掰扯,使部门间的协同效率更高。

  这就是建立运营流程的过程。但是也要强调一点:不是所有的职能边界都可以划分的很清晰,工作边界划分的界限与不断发展的工作内容有时间上的滞后性。

  事情在未划分清楚前一同面对解决是要保持的良好工作习惯,事情第一,分歧第二。

  签约时效看公司合规的要求,有些公司简单,有些公司复杂□□□□,一般受国家监管的行业流程都会比较长。

  一般来说可能填写一张盖章申请表找若干领导签字就结束了,复杂的业务可能内部要企划、财务、法务等各个部门各层级领导逐一审批。

  这个根据公司的不同情况制定,不脱离实际即可。只是在制定标准的时候□□□,切记要明确各环节的处理时效及要求;以及对接人事前要明确,做好沟通。

  客服流程:旨在建立售后服务标准□□□□,搭建与客户的联系桥梁,及时响应客户需求,提高产品在行业内的口碑。

  对外的客户服务信息一般都会提供客户服务经理的手机和邮箱,有些公司也会提供在线提交生产问题(BUG)或者操作类问题的工具类似于工单系统。

  结算流程:根据结算方式有一次性付款、预存和按约定结算包括月度结算和季度结算。一次性支付适用实施交付类型的,按季度结算比较适用于按使用量收费的项目。结算要按照合同约定的结算方式和结算时间,把握好结算各环节的处理时效。

  新需求流程:客户上线运营一段时间后□□□,不可避免的客户、BD包括运营本身都会提出一些新需求。需求一些容易导致需求在技术开发那边排队等待发版上线,这时候就需要运营对新的需求进行把控。

  最有效的方式就是做好需求的过程管理。同时□□□,对需求进行分级□□,可以按照L1-L2-L3-L4来对需求进行分级□□□□,分级的同时要说清楚不同级别的需求是如何定义的。

  在产品上线前一定要做好产品培训。整个流程的制定可以从培训前、培训中和培训后三个阶段考虑,培训的目的是让内部、外部客户了解、熟悉产品。

  在上线前做好培训其实是一件很不容易的事情。如果是提供API或者SDK,只需要对接技术就行了,产品的使用客户会内部消化掉。

  某些产品是提供一整套系统服务,涉及到客户方的诸多部门和人员。每个人的接受能力、理解能力和学习态度都是不同的。这时候想要做好培训的难度是极大的,极具挑战性。

  产品使用手册要简单易懂:一般产品经理给客户的培训手册是一个非常专业的产品文档,专业词汇解读,流程说明的很详细,专业人士一看就明白是啥。

  但是□□□,作为一个小白用户呢,看到文档一定是俩眼一抹黑,每个字看上去都懂,连在一起就不知道是啥了。但是最专业的不一定是客户最适合的□□□□,客户最需要的是一个简单的能看的明白的,最好是告诉客户第一步你要做什么,第二步你要做什么,一个给大妈都能够看懂的文档。

  建立考核机制:为了确保客户的员工能尽快掌握产品,最好和客户一起建立产品使用培训考核机制□□□,推动客户的员工尽快熟悉产品。

  产品上线后的问题处理一般可以分为三类:BUG类问题、操作类问题、以及运营管理类问题。

  不管何种问题,我们都需要把问题进行闭环处理□□,这块的像操作类、运营管理类问题很多是需要和产研部门达成协同完成的。操作类问题也可以进行定位,通过产品优化的方式降低操作风险。这就需要我们一定要把整个产品优化的闭环流程设计好。

  通常80%的收入由20%的客户提供的,这是市场不变的定律。然而资源的总量是恒定的,所以我们在运营工作中投入的资源是有限的,这就决定了资源分配的不均衡性。因此□□□,在实际的运营工作中我们必须做好客户的分类经营。

  客户分类也可以叫客户分级体系,不同类型的公司对于客户分类的方法也不同,但是原理一致:根据客户的重要程度进行分类。常用的分类方法是S、A、B、C。

  S类客户是指对于公司的战略有重大影响或者在公司的营收中占比很高。这类客户一般是行业龙头,与我们的合作不仅仅期望提供服务,并希望借此合作机会对双方的品牌影响力都有提升。这类客户必须抽调最优质的运营资源比如专属的运营服务团队□□,研发团队等。

  A类客户是指该类型的公司在公司的战略方向,并且在行业内有一定的影响力□□□,或者该公司的营收占比较高□□□□,这类客户可以提供专属的运营人员和产品经理等,提供1对1或者1对2的服务;

  不同的2B服务制定的服务标准也不一样,具体我们要如何制作客户分类标准要根据企业实际提供的服务来看□□□,不可生搬硬套。另外B端产品运营相对于C端来说,可玩可创造的方式方法会少一些。

  搭建起运营体系只是第一步□□,最终产品运营的效果如何,需要用一种量化的方式来呈现和优化参考□□□,通过建立业务核心指标直观的表现产品的运行效果,就是需要做好产品数据的运营。

  数据运营包括核心指标体系和数据分析体系:核心指标体系可以监控用户运营的发展趋势,实时了解用户活跃度、健康度等基本信息;用户数据分析体系能够帮助运营人员定位问题,并针对问题及时优化产品。

  核心指标体系的搭建一定与产品目标紧密结合。比如:单车类产品目标是获得租车收入□□□□,其核心指标应该以付费用户为核心进行搭建。同时□□□,核心指标数据在企业内部不同层级的人员关注点也不一样。领导层级关注的是大盘用户体量、成本、收益;运营层级关注的是用户活跃度、留存度、转化情况。

  在指标体系产品的搭建中,我们围绕消费用户核心指标从新获客能力、 健康度、偏好度、关键行为四大维度进行构建。

  用户增长潜力分析:通过关键行为环节中的前置行为对用户增长的潜力进行分析;

  用户来源渠道分析:用户主要从哪些渠道来的?哪些渠道优质□□,从而优化渠道策略;

  拉新产品分析:哪个产品拉新贡献最多,客户首次下单的产品定义为拉新产品;

  拉新偏好分析:新用户的偏好,比如:生鲜类中的鸡蛋,可以后续作为引流产品。

  用户价值分析:忠诚用户群是谁,活动时候可以找这些优质用户让他们来参与;

  不同用户群的重复使用:老用户的重复使用偏好,及时调整新老用户运营策略,按月度监控;

  数据分析体系,需要搭建系列分析模型工具,帮助运营人员定位运营过程中的问题。模型工具包含漏斗分析模型、归因分析模型、微转化分析模型、同期群分析模型等。

  但是传统的增长一般想到的是渠道运营,加大投入等等。但是在现在这么复杂的运营体系情况下,如果只是加大流量的方式□□,协同效应是无法起来,很容易任务分配下去,各自负责一块,各自去达成KPI。

  最普遍的做法就是付费渠道全面开花,核心增长渠道无法集中精力培育,CAC居高不下。所以在成熟体系下做增长需要注意以下要点:

  增长团队首先要消除部门边界,以项目组形式或增长部门存在□□□□,包含渠道运营、活动运营、产品、用户运营。其次基于AARRR每个运营节点,为各个职能定义增长指标来指导整个增长工作:

  渠道运营在Acquisition节点主要考核:新增用户、获取成本(CAC)、新增用户留存率。

  产品在Activation和Retention节点主要考核:注册转化率、功能留存率;

  用户运营在Revenue和Referral节点主要考核:用户转化率和K因子。

  然后以项目组或增长部门的形式将各个节点统筹起来□□,最终在KPI层面只考核整个项目组的指标,每个职能都与这个指标相挂钩□□,解决了各自为政和相互推诿的问题。

  项目组的任务就是建立用户核心增长渠道□□,首要目标之一就是找到CAC足够低的渠道。如果获取用户付费渠道占比很高,用户获取成本居高不下,那么增长就受制于推广预算,增长在预算不足时候就会出现停滞。其次核心渠道带来的用户一定是优质的用户。

  增长工具就是能够帮助企业高效获得用户的手段,可以是实物,也可以是券之类。例如摩拜的增长工具就是单车本,通过单车和用户短途出行需求的结合□□□,爆炸式的获得大量短途通勤用户;滴滴的增长工具就是补贴券,通过券将大量打车边缘用户转化为使用用户。

  增长工具作为获客利器,要与企业核心业务紧密结合□□□,同时又能够切中用户需求,两者缺一不可。如果无法找到增长工具,靠刷脸的方式是无法获得持续用户增长。

  实际增长过程中,不是一蹴而就□□,还是需要根据数据及业务分析而得□□□□,甚至也会做小规模试点。这点针对高频业务交易类产品提供了一个241增长方法□□□,具体就是两个前提,四个判断。

  两个前提:市场够大(有空间)、留存率够高(产品力)。这个就不赘述□□□,肯定是增长的前提。

  如果是平台类的业务可以衍生出若干运营场景,每个场景下需要对不同的用户群进行运营□□,用户群来自与标签模型及各个用户模型。

  在具体运营过程中□□,除了growth hack□□□,还有用户精细化运营。两类运营细分具体的场景,以其中一个运营场景举例:

  业务场景:平台某频道用户复购率较低,怀疑用户流失严重,希望用户部门帮助监测用户流失情况□□□,并预测现有哪些用户可能会流失?

  结合这个业务场景□□□□,我们会在标签系统里,筛选出打上频道标签的用户;并通过用户流失预警模型来训练流失用户样本;通过模型可以将流失用户特征找出来,并计算不同特征用户的流失得分;以流失得分对用户进行分群。

  具体可以组合为低风险流失用户、中风险流失用户、高风险流失用户。低风险用户群可以保持现状□□,进行日常推送营销□□,对于中高风险流失用户群,需要结合用户画像系统和用户偏好分析模型分析来确定触达策略。

  整体上说运营是充分调动内外部资源□□,对于公司的经营运作全面负责,肯定是需要一套的运营体系来进行支撑。但是构建起了运营体系,并不能保障一定就有成果,而是建立起一个较为完整,且可以实现不断提升的效果的稳定运转机制。

  但是因为运营工作的繁杂,所以怎么优化人员的职责,解决人员之间的协同效率就是个难题。

  很多运营部门的工作职责很容易陷入,一开始人招少了,导致人人琐事缠身,绩效无法责任到人;于是就加招人手□□□□,然后又招多了□□□,导致人浮于事。甚至有见过超过几十人团队的运营部门,仍然是采用师傅带徒弟的方法。

  我当时的说法就是:这是给每个能干活的人招一个不能干活的助理。结果就是没有一个高效的组织体系□□,这是很要命的问题。所以运营部门如何搭建这个问题值得探讨下。

  职能的划分肯定是部门搭建的重要依据□□,运营的职能很宽泛,而且每家公司的运营特点也不一样,但是我们还是可以划分出一个脉络来:包括产品力、营销、运营服务、数据分析四个层面。

  商品职能:包括服务类商品□□,也包括电商平台的商品品类供应。包括商品的产品力提供及部分商品包装的工作;

  流量运营:扩大内外部引流渠道,流量精细化运营□□□□,联合渠道活动,外部投放,PC导流,移动沉淀□□□□,后期的转化率等;

  用户运营:根据用户漏斗模型、RFM模型□□□,建立用户分级运营体系;根据不同阶段的用户特征□□□□,建立对应的运营机制,提升新用户转化率,老用户ARPU值;做大用户规模□□,构建合理的用户结构;

  活动运营:根据热门活动周期及重要的时间节点策划活动,刺激用户□□,增加用户贡献值□□,带动增长;

  产品运营:根据用户数据漏斗模型,分析用户流失原因□□□,优化产品流程□□□□,提升各个环节的转化率;策划活动促进用户对新产品的认知及新产品的用户导入;

  运营工具:根据运营需求策划运营工具□□□,推出产品实现。包括但不限于:体验金、抵用券、体验课、秒杀、加息、抽奖、返现券等;

  确定了职能并不能说就是把组织架构确定了,关键还是要根据公司的实际情况,最优的方式协同起来。

  这就要看选择什么样的结构最为合理。从组织结构上来说,有直接的职能型组织、项目型组织、矩阵型组织。组织结构的选择是对项目产品的基础支撑,组织结构的设计也可以看做是运营本身。

  职能型组织是把相同职责的人划分在一个部门里,有利于同类资源共享□□□□,互相学习提高□□,但公司的目标在分解到各部门。

  但问题就是目标很容易不一致,因为每个部门客户这时候变成了上面的管理者,都只是对领导负责□□,没有人对真正的客户负责。但是这也不影响这种组织形式的价值,在大规模运作的公司□□□□,更多的推动来自公司的战略。

  人本身就是资源,这种组织形式的优势就是推动效率较快,每一块能有专业项上的资源沉淀。

  项目型组织与职能型组织正好相反□□□□,是把各种职责的人组成一个个的项目组,团队目标一致。

  优势是目标清晰整齐,有利于快速推进项目;但是如果公司项目较多的情况下□□,会造成资源的浪费,而且对每一块的负责人提出了较高的要求。

  如果把产品技术团队也合并进来,这样的项目组发展下去就是事业部□□□,甚至是独立公司。

  矩阵型组织则是上述两种组织结构的融合,横向是产品业务线□□□,对客户负责;纵向是资源行政线□□□□,为了资源共享。如果说职能型组织比较适合防守型的业务□□□□,项目型组织适合进攻型业务□□□□,矩阵型组织就是可攻可守。

  但它也有很明显的问题:就是多头管理的问题。对员工来说,一面是部门经理,另一面是业务线经理□□□,这样的双头领导总是很让人头疼。就算这两种职位有时可以通过兼任来解决矛盾□□□□,但对人员就提出了较高的要求。

  因为产品业务线的负责人主要管事□□□□,像猎人追求成就感,具体对打仗负责;资源职能线的负责人主要管人□□□□,像农民对人负责,追求权力和控制。

  如果上一层的管理不当职责划分不清就会导致两个负责任扯皮不断。但是如果职能资源同时兼任产品业务线□□□□,又会导致用权力来寻求成就感,或者在KPI的重压之下□□□□,放弃猎人的追求,造成行为的短视,忽视团队能力的提升。

  肯定没有□□,每家企业的运营模式代表企业的核心竞争力,肯定没有最优解。而且每家企业拥有的资源和所处阶段也不同,所以团队架构本身肯定是一个不断升级的过程。

  对于创业初期的时候,运营的全面负责任应该是CEO,对公司内外关键资源进行协调。

  要戒掉一开始就打造个什么标准化的运营团队的念头。一个新的项目,既没有人又没有资源凭什么,如果按照标准模块搭建起的运营团队肯定是扯淡,人浮于事;

  要注意人员的培养,按目标去组织人,而不是按人来分配岗位。更重要的是要不断的在目标上去寻求更多的渠道或方式的可能性,甚至可以多个项目并存同时去尝试□□□,快速尝试快速改正。

  无论是外部客户获取,还是内部运营协同,这个阶段就要去选择过度。可以将一些可以固化的人员固化到职能型,按照职能型去管理。但是要避免掉因组织变更带来的优势丧失□□□□,导致结果不可保障。

  这个阶段肯定会存在人员的冗余。所以在这个阶段,必须做好判定:根据公司的资源资金以及快速发展趋势上,选择相应的方式来过度。既要解决人的沉淀问题□□□□,未下一阶段做好储备;又不能导致团队的崩塌或结果的不可控。

  在这个例子中,运营服务和设计服务组是基础保障,保障服务的正常运行。付费推广组是目前已验证的流量渠道,保障业务的结果可控。数据分析组是后期加上的,通过数据分析发现客户的留存存在问题□□,所以才增设了CRM组。在过度阶段形成了这么一个结构。

  矩阵式管理的优势都了解□□□□,但是怎么做到矩阵式,就需要前期的沉淀。包括人员的沉淀是基础,没有人怎么说都是白搭;同时企业也得具有扁平化管理的文化基因□□□□,如果缺乏这个基因,首先在沟通上就没有边界,会有无数的扯皮出现。

  整体上说运营是充分调动内外部资源,对于公司的经营运作全面负责□□□,肯定是需要一套的运营体系来进行支撑。

  但是构建起了运营体系,并不能保障一定就有成果;而是建立起一个较为完整,且可以实现不断提升的效果的稳定运转机制。

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台□□□□,集媒体、培训、社群为一体,全方位服务产品人和运营人,成立9年举办在线+期□□□□,线+场□□,产品经理大会、运营大会20+场□□,覆盖北上广深杭成都等15个城市□□,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里与你一起成长。

评论】【加入收藏夹】【打印】【关闭】【进入论坛讨论】【回顶部

评分: 1分 2分 3分 4分 5分 平均得分: 分,有 人参与评分.
发表评论:(可直接用论坛账号评论) 共有条评论 查看全部评论

查看全部评论

最新教程

热点教程

推荐教程

新闻资讯

关于我们| 客户案例| 起啟论坛| 服务项目| VIP服务| 联系我们| 客户服务| 免责声明| 意见反馈| 广告服务
Copyright@http://www.qiqig.com all rights reserved 粤ICP备06112835号
Powered by 起启网页学院 Code © 2003-07 QiQiG.CoM