迪拜创业公司使用 Ruby on Rails:哪些场景依然合理,哪些场景已经不再合适
迪拜创业公司使用 Ruby on Rails 依然合理的场景、阿联酋的招聘现实,以及创始人何时应该另作选择。
阅读文章迪拜 Shopify 网站开发被默认推荐的频率,比它本该被推荐的频率要高。对很多阿联酋卖家来说,Shopify 确实是个不错的选择,但真正重要的决定,发生在挑选任何主题之前:一个由应用驱动功能的托管平台,是否适合这家企业实际的销售方式,还是自建商店,或者别的什么方案,才是更诚实的答案。本页专门讨论的是,在这项决定已经做出之后的 Shopify 本身,以及一份通用 Shopify 指南从不会涉及的阿联酋建站细节:哪些支付渠道真正适用于一家在阿联酋注册的公司,货到付款如何与快递员实际收取的款项对账,订单一旦离开迪拜配送成本会如何变化,以及一个真正从右到左排版的阿拉伯语店面,在 Shopify 的主题结构里到底需要什么。
Shopify 网站开发隶属于我们更广泛的网站开发业务。如果你想不局限于特定平台地了解如何搭建一家线上商店,包括税务发票和平台比较,可以参考电商解决方案;如果想提升现有商店的曝光度,可以参考电商 SEO。
真正的决定
Shopify 网站开发的第一步,是诚实地评估适配度,因为一旦一年的产品目录和订单都沉淀在某个平台里,选错平台的代价会非常昂贵,很难逆转。
| Shopify 往往更胜一筹的情况 | 自建商店往往更胜一筹的情况 |
|---|---|
| 你想上线,却不想自己管理服务器、安全补丁或正常运行时间 | 你已经在用 WordPress 管理内容,并希望商店建在同一个网站里 |
| 你的产品目录和结账逻辑,在应用和 Shopify 自身设置能覆盖的范围之内 | 你的定价、组合销售或结账规则特殊到应用无法干净地表达 |
| 你想要一个成熟、丰富的应用目录,来覆盖评价、订阅等常见功能 | 你想在代码层面完全掌控结账流程,不想叠加一堆应用订阅费用 |
| 你能接受由 Shopify 自己的发布节奏,来决定改动什么、何时改动 | 你希望自己能精确掌控底层平台何时发生变化 |
抽象地说,两个答案没有孰优孰劣。一个只卖四十款产品、只有少数几个规格变体的精品品牌,通常从第一天起就能被 Shopify 很好地满足。而一家有租赁预约、分级批发定价,或是从 ERP 系统同步过来庞大产品目录的企业,往往需要的东西超出了 Shopify 应用生态能够舒适提供的范围。真正诚实的测试,不是看哪个平台听起来功能更强大,而是看两年之后,当产品线和订单量都增长起来的时候,你实际的产品目录、团队和系统集成,依然能否舒适地容身其中。
主题
Shopify 网站开发通常从这个选择开始,它既是一个设计决定,也是一个开支决定。一款在自身设置和分区内配置好的现成主题,能让商店更快上线,并且让后续的改动始终停留在店主自己不靠开发者也能完成的范围内。一款专为品牌定制的 Liquid 主题,只有在现成主题目录确实无法交付品牌所需要的布局、双语行为或产品展示方式时,才值得付出那份成本,而不是仅仅因为“完全定制”听起来更正式。
居中的做法,是在一款现成主题的基础上,用大量自定义分区和区块进行深度定制,这条路能很好地覆盖大多数迪拜卖家的需求。它既保留了 Shopify 自身的更新路径,又能让品牌拥有一个不像未经修改的模板那样的店面。
应用
一款能把某一个问题解决好的应用,是 Shopify 真正的优势之一。而一个被十几个小额订阅拖累的结账流程,则是它真正的风险之一。
大多数能带来真正功能的应用,评价、订阅、高级配送规则、会员忠诚度,都会在你的 Shopify 套餐之外附带各自的持续订阅费用,单独计费,也很容易被人遗忘。
一个把自身代码注入店面的应用,和任何第三方脚本一样都会增加重量,这也是为什么 Shopify 网站开发把选择应用当作一项性能决策,而不只是一项功能决策。
当一款应用只能大致满足企业的需求,而这个差距在结账环节造成了真正的摩擦时,在主题内做一次小规模定制开发,或使用一个 Shopify Function,效果往往会胜过三个功能重叠的应用叠在一起。
在推荐任何一款应用之前,我们都会先确认它到底做了哪些 Shopify 自身设置还没覆盖的事,并且在添加新应用之前,先检查商店现有的应用列表是否存在功能重叠,因为 Shopify 网站开发经常接手那些同时装着两三个功能相近应用的商店。
支付
Shopify 自己的文档把阿联酋列为Shopify Payments可用的国家之一,这意味着一家在阿联酋注册的企业,原则上可以通过 Shopify 内置的网关接受银行卡付款,而不需要向第三方提供商单独申请商户账户。至于这条路径是否适合某一家具体的商店,还要看结算币种、你的客户实际使用的卡组织和电子钱包,以及账户验证流程和你公司的证件是否匹配。
如果企业出于某个特定电子钱包、更低的成本结构,或是已有的商户合作关系,而选择使用第三方网关,Shopify 同样支持这样做,Shopify 网站开发也经常正是出于这些原因去接入某个网关,而不是默认使用 Shopify 自家的网关。有一个值得提前知道的实际细节:对于通过 Shopify Payments 以外的网关处理的订单,Shopify 会在该网关自身的手续费之上,额外收取一笔自己的交易手续费,所以第三方网关的真实成本,是两笔费用叠加,而不是一笔。
货到付款
货到付款在整个阿联酋的线上订单中依然占据相当可观的比例,Shopify 商店会把它设置成一种人工支付方式,而不是通过银行卡网关处理:订单在没有扣款的情况下就被确认,款项则在包裹送达时由快递员收取。让卖家措手不及的,往往不是设置本身,这一步很直接,而是事后的对账,因为 Shopify 并没有一种自动方式,能知道快递员是否真的为某一笔订单收到了本该收取的现金。
如果商店要提供货到付款,Shopify 网站开发就应该从一开始就把这道对账流程建进去:有一种方式能在快递员确认之后,把订单标记为已收款,并且能清楚看到哪些订单迟迟没有确认,因为这些订单最有可能需要一通跟进电话,或需要处理一次配送失败。
配送
一家总部在迪拜的商店,配送成本很少是一个单一的固定数字,Shopify 自身的配送设置需要真实的数据输入,才能反映这一点。
通常是速度最快、配送成本最低的一档,如果你的快递公司确实支持,当日或次日达在这里也是现实可行的承诺。
沙迦和阿治曼距离迪拜足够近,运输时间几乎不变,但快递公司的价格档位往往依然和迪拜费率不同。
哈伊马角、富查伊拉、乌姆盖万和艾因都会增加真实的运输距离,在这里统一采用一个全国统一费率,往往要么在较远的配送上亏钱,要么在较近的配送上多收了钱。
把生意做到更广泛的海湾地区乃至更远的地方,需要一份单独的费率表,通常还需要一套完全不同的快递合作关系,下文会在 Shopify Markets 部分单独说明。
Shopify 的配送设置可以承载按区域划分的费率,但必须有人先为一家阿联酋企业正确地划定这些区域和档位。Shopify 网站开发应该依据你实际的快递合作协议来搭建这些设置,而不是套用一个把送到迪拜和送到富查伊拉一视同仁的、笼统的全国默认值。这件事一旦出错,很少会表现为一次明显的失败,而是慢慢地体现在远距离订单利润逐渐变薄上,而这一点从来没有人真正对照过快递公司的实际发票去核查过。
阿拉伯语
Shopify 自己的主题文档把语言文件,也就是存放主题所用已翻译文字字符串的 JSON 文件,描述为给店面添加另一种语言的机制。这解决的是文字的翻译问题,但本身并不能解决一个真正从右到左排版的店面所需要的东西:镜像的导航、对阿拉伯语读者来说流程正确的结账、在从右到左网格中表现正常的产品卡片与筛选器,以及为可读性而专门选择的阿拉伯语字体,而不是任由它退回到某种拉丁字体的后备方案。
正是这个缺口,催生出那些看起来像阿拉伯语、但在迪拜购物者眼里读起来却像是被翻译过的英文网站的 Shopify 商店。要打造一家真正双语的商店,Shopify 网站开发会从主题搭建之初,就把阿拉伯语版本当作一项模板级要求来对待,这和我们在阿拉伯语网站开发页面深入讲解的原则完全一致,只不过是具体落实在 Shopify 的分区和语言文件结构里,而不是想当然地以为它会自动发生。
迁移
一次迁移成败与否,取决于数据和网址最终的命运,而不是新主题看起来完工得有多快。
产品、规格变体、图片、客户记录和订单历史会从当前平台导出,并逐字段映射到 Shopify 的结构上,因为两套系统几乎从不是一一对应的。
迁移过程会先在一个尚未连接到你域名的 Shopify 商店里完成,这样产品目录、定价和阿拉伯语内容都能在正式上线之前被完整核查一遍。
每一个现有的产品、分类和内容网址,都会通过永久重定向映射到它在 Shopify 上的新地址,这样搜索排名、收藏夹和已分享的链接就都能继续生效。
支付网关、配送区域、税务设置和分析工具会在切换之前重新配置好,并用真实的测试订单进行验证,而不是等到第一笔真实订单才发现哪里没配好。
域名会被指向新的 Shopify 商店,旧平台会在一段时间内保持可访问但不对外公开,而订单、重定向和搜索可见度,则会在最初几周内被密切关注。
所有权
这个问题值得在项目开始之前就得到一个直截了当的答案,而不是等到企业已经在这个平台里积累了三年订单之后才问。
| 归你所有,可以导出 | 建立在 Shopify 平台之上 |
|---|---|
| 你的域名和 DNS | 店面主题的 Liquid 代码和结构 |
| 你的产品目录,可导出为表格 | 应用配置以及任何特定于应用的数据 |
| 你的客户名单和订单历史,可导出 | 结账流程的定制,受限于 Shopify 结账系统所允许的范围 |
| 你的产品摄影和文案内容 | 基于 Shopify API 构建的定制 Shopify Function 或后端逻辑 |
日后离开 Shopify,意味着你的业务数据会跟着你走,但店面本身必须在你迁移到的新平台上重新搭建。这个取舍值得在 Shopify 网站开发一开始就弄清楚,而不是在商店已经运营了三年之后才发现。
拓展销售
Shopify 的 Markets 功能能让同一个商店,基于同一份底层产品目录,向不同地区展示不同的币种,以及在配置好的情况下展示不同的语言。
价格可以按每个市场单独设定或调整,而不是仅依赖单一的自动汇率换算,这一点在一个阿联酋品牌开始向海湾其他国家发货之后就会变得很重要。
即便店面按地区呈现出不同的样貌,库存、订单和报表依然集中在同一个地方,这是相对于完全分开运营多家独立商店的主要实际优势。
对于一个在阿联酋以外确实有真实需求的品牌来说,Markets 是一项值得使用的真正功能。但它本身不能替代前文提到的阿拉伯语店面工作;一个配置为阿拉伯语的市场,依然需要前面所说的那套从右到左的模板工作。
性能
Shopify 托管了整个平台,这消除了一整类速度问题,但并不能消除所有速度问题。
服务器基础设施、结账安全性和正常运行时间都由 Shopify 负责,对于没有内部工程团队的阿联酋卖家来说,这是这个平台真正的优势之一。
主题的重量、图片尺寸,以及有多少应用把自己的脚本注入店面,依然完全在店主的掌控范围内,一家速度较慢的 Shopify 商店,时间通常就是耗在这些地方。
我们网站速度优化页面里讲到的原则,也就是从真实访问而不是单次测试来衡量 Core Web Vitals,同样直接适用于 Shopify 店面,尤其是图片密集的产品页面。
结账
Shopify 的托管结账,是这个平台最强的卖点之一,也是它最坚定的边界之一。它速度快,经受过任何小型开发团队都无法匹敌的规模测试,银行卡数据的 PCI 合规由 Shopify 负责,而不需要店主自己承担这份责任。付出的代价是定制自由度:在大多数 Shopify 套餐里,结账页面的布局、字段顺序和品牌元素可以在 Shopify 自身的设置里调整,更高级的套餐还能使用结账扩展,但底层的结账流程本身,并不像自建商店的结账那样可以被完全重建。
对大多数迪拜卖家来说,这笔取舍其实是有利的,因为一个经过测试、安全的结账流程,比一个完全定制的结账流程更重要。Shopify 网站开发会及早标记出例外情况:如果一家企业的结账真的需要一个 Shopify 结账无法表达的步骤、字段或规则,那么让它在项目开始之前就了解这一点,要比等店面建好之后才发现好得多。
产品目录
一份没有结构地不断增长的 Shopify 产品目录,会变得越来越难浏览,也越来越难筛选,这首先会表现为分类页面跳出率的上升,而作为数据问题被注意到往往是后来的事。规格变体,尺码、颜色、材质,能很好地处理真正的产品选项,但它并不是表达每一种区分的合适工具;如果硬把系列或季节这类信息塞进规格变体里,往往只会做出一个臃肿、混乱的产品编辑界面,而不是对购物者有用的筛选功能。
对于一个产品在核心规格变体之外还需要的结构化细节,养护说明、材质成分、兼容性,或是阿联酋市场上一次慎重购买在下单前往往需要的那种参数表,Metafields 是更合适的工具。在 Shopify 网站开发一开始就把 Metafields 正确设置好,而不是等产品目录已经涨到几百个产品之后再回头补,第一天多花的这点时间,日后能省下远不止这些。
追踪
一家没有可靠追踪的商店,无法分辨一个产品页面做得好还是不好,而 Shopify 自身的报表只能覆盖这幅图景的一部分。
正确接入购买、加入购物车和结账事件,这样广告活动的表现就能按实际营收来判断,而不只是靠点击量。
Meta、Google 以及其他任何广告像素,都要配置成在正确的事件上触发,不重复计算也不漏计购买次数,这是那些装了好几个各自带有追踪功能的应用的商店里常见的毛病。
追踪设置要尊重访客的同意选择,而不是不管三七二十一都触发,这既关系到合规,也关系到商店报出的数字是否值得信任。
这部分工作和我们的网站分析服务紧密重叠,对于一家新商店,Shopify 网站开发应该把分析工具的搭建当作上线工作的一部分,而不是等商店已经开始接单几周之后才补上的任务。
拓展销售模式
并不是每一家 Shopify 商店都只是一份单纯的一次性购买目录。越来越多的迪拜卖家希望为重复购买的产品提供订阅选项,或者在零售商店之外再开辟一条独立的批发或贸易渠道,而 Shopify 的应用生态对这两种常见情况都覆盖得相当不错。订阅类应用负责处理周期性扣费和客户自助管理;批发业务则可以通过一个专门的商业渠道来运行,也可以在主商店内通过客户标签和分级定价来实现,具体取决于这两类受众需要分开到什么程度。
这些模式变得复杂的地方通常在边缘情况:配送间隔不规律的订阅,或者批发价格取决于某个客户特定的谈判条件,而不是一个固定档位,这正是通用应用最容易力不从心的地方。Shopify 网站开发应该诚实地说明,一款应用在哪些地方能舒适地覆盖需求,又在哪些地方开始吃力,因为硬把一个不寻常的定价模式塞进一款为更简单场景而设计的应用里,是持续技术支持头痛问题的常见根源。在项目开始之前就被坦率地告知这一点,而不是等到上线之后才发现,对一个正在成长的阿联酋卖家来说,通常比一个乐观的答案更有价值。我们宁愿在需求简报阶段就坦承 Shopify 不适合某个业务,也不愿交付一家从一开始就与它本该支撑的商业模式相互别扭的商店。
交接
一家没有经过妥善培训就交接的 Shopify 商店,往往会一直保持上线当天的样子,因为团队里没有人有足够的信心去碰它。
一份录制下来的、实操性的演示,涵盖添加产品、设置折扣、处理订单和办理退款,作为你的团队日后可以随时回顾的参考资料。
针对你的主题内置的具体分区和区块进行培训,这样首页和活动页面的常规更新就不需要靠开发者来完成。
一份清单,列出商店接入的每一款应用、网关和系统集成,并把管理权限正式交接过来,而不是留在开发者自己的账户里。
在正式上线之后设一段支持期,用来解答问题、处理一些小修小补,让你的团队逐渐适应日常运营这家商店。
移动端
如今大多数访问迪拜线上商店的流量都来自手机,而 Shopify 的默认主题从一开始就是响应式设计,这省去了自建商店往往需要从零解决的一个顾虑。不过,响应式并不等同于真正适合手机购物。需要精确点击才能滑动的产品相册、为宽屏设计却被硬塞进窄屏的筛选面板,或者尺寸是为鼠标而不是拇指设计的结账字段,这些问题依然会出现在一个技术上完全响应式的 Shopify 主题里。
Shopify 网站开发应该在上线前用真实的手机测试完整的购买路径,浏览、筛选、加入购物车、结账,而不只是检查布局在缩放时是否正常。这是两种不同的测试,而只有其中一种,才能告诉你一位真实的客户能否在他们大多数人实际使用的设备上,舒适地完成一次购买。
搜索
Shopify 默认就能把技术基础打理得相当不错,这把真正的工作重心转移到了结构和内容上,而不是底层配管工程。
Shopify 默认的产品和系列网址结构基本可用,但比起完全定制的建站方式要略显僵化。从一开始就把 URL handle 定对,能避免日后一堆杂乱的重定向。
一个带有真实介绍性内容和清晰筛选功能的系列页面,通常比一个只在上面贴了个标题的光秃秃产品网格,排名和转化都要好得多。
在一个较大的产品目录里,筛选和排序参数可能会产生大量近似重复的网址,这需要专门处理,而不是任由它不断累积。
本页涵盖的是 Shopify 网站开发从一开始就应该在结构上做对的部分。至于一家线上商店持续性的关键词和内容工作,包括分类页面和产品页面应如何排定优先级,详见我们的电商 SEO页面。
退换货
在 Shopify 建站过程中,退换货处理很容易被当作事后才想起的事,而它往往是订单出问题之后,客户第一个会去测试的地方。一份只存在于一个没人会读的页面上的政策,和一套真正能运转的流程完全是两回事:Shopify 自身的订单管理能追踪一次退货或换货,但快递上门取件、退款到账时间,以及一笔从未收取过银行卡付款的货到付款订单该如何退款,都需要在第一次真正发生退货之前就有一个明确的答案。
Shopify 网站开发应该用对待购买路径同样的用心程度,来对待退货路径,因为一次顺畅的退货,是一家线上商店能给出的最有力的信任信号之一,而一次笨拙的退货,被人记住的时间会远远长于一次顺畅的结账。
常见错误
| 我们发现的问题 | 它对企业实际造成的代价 |
|---|---|
| 三个功能重叠、做着大同小异工作的应用 | 持续叠加的订阅费用,以及一个比商店本该有的速度更慢的店面 |
| 阿拉伯语页面已翻译,却依然保留从左到右的布局 | 阿拉伯语访客看到的网站显得像没做完,在最要命的时刻削弱了信任感 |
| 提供货到付款,却没有对账流程 | 没有人能有把握地说清楚,哪些货到付款订单真正收到了款 |
| 所有酋长国统一使用同一个配送费率 | 要么在远距离配送上亏钱,要么在近距离配送上多收了钱 |
| 只看品牌名气就选定的网关,没考虑费用叠加情况 | 每一笔订单都白白多付了一笔本可以避免的交易手续费 |
内容
Shopify 网站开发完全可能围绕着还没准备好的产品内容,搭建出一个技术上无可挑剔的商店,而这个差距会在真实客户到来的那一刻立刻暴露出来。不同批次拍摄风格不一致的产品照片,直接从供应商在另一个市场自己的目录里照搬的文案说明,或是把阿拉伯语版本当作低于英语版本优先级来对待,都会削弱一家原本运转良好的商店。这不是在批评哪一家企业,只是说产品内容最常在建站进度上掉队的地方就在这里,因为摄影和文案通常由和网站项目本身不同的团队或供应商负责。
围绕着还不存在的内容,去搭建商店的信息架构,分类、筛选器、Metafields,这在技术上是可行的,但这意味着在猜测那些本该由内容来驱动的结构。当内容还没准备好时,Shopify 网站开发更好的做法是围绕着这个现实来排定顺序:先早早定好结构,内容同步生产,等两者都准备好之后再填充商店,而不是带着占位文字上线,让这些占位文字悄悄变成了永久内容。
安全
运营一家线上商店存在真实的欺诈和数据风险,有必要说清楚,这份责任在 Shopify 平台上究竟落在谁的肩上。
银行卡数据安全、结账本身的 PCI 合规,以及底层平台的基础设施安全,都由作为托管服务提供商的 Shopify 负责,这为一个小团队卸下了一份确实很棘手的责任。
订单层面的欺诈审核、员工账户的访问权限、安装应用前的审查,以及客户数据在 Shopify 自身系统之外如何被使用,这些依然是企业自己必须做出并管理的决定。
Shopify 会对订单提供内置的欺诈分析标记,这是一个有用的信号,但不是一个可以直接依据的决定,对于同时接受货到付款的商店尤其相关,一笔被标记的订单,值得在发货前再看一眼。我们不是安全认证机构,你的企业在 Shopify 自身提供的保障之外还有的任何具体合规要求,都应该向你自己的顾问确认。这只是对这个平台上责任归属的一份实用性说明,不是法律意见,任何与你所在行业相关的监管问题,都值得寻求专门的合格建议。
上线之后
建站是 Shopify 网站开发里相对好规划的那一半,因为它有一个明确的终点。上线之后发生的事,才决定了一家商店是持续改进,还是慢慢走偏:新产品添加时不再像最初的产品目录那样用心,季节性活动又叠加上一款新应用,阿拉伯语版本随着新内容不断加入,不知不觉就落后了英语版本一两个页面。这些都不是出于疏忽,而是因为最初的项目团队离开之后,没有人负责让两个语言版本保持同步。
一份简短的长期安排,哪怕规模不大,涵盖定期的应用和性能复查、产品目录结构检查,以及确认阿拉伯语内容是否跟上了进度,往往就是一家商店在上线一年后依然显得用心经营,和一家已经明显走偏的商店之间的区别。它不需要是一项浩大的工程才能有效;按下面这些要点每季度做一次简短检查,通常就能在客户注意到之前捕捉到偏差。这件事不需要面面俱到才有价值,它需要的是被排进日程,而不是等某个人碰巧注意到问题才去做。
开始项目
产品数量、规格变体,以及产品线是稳定不变还是经常调整,这样我们才能判断这次建站该有多少依靠应用、多少需要定制开发。
你目前或计划使用的支付网关、货到付款是否重要、你的配送区域,以及阿拉伯语是从上线之初就需要,还是之后再添加。
如果你现有的商店建在另一个平台上,也请告诉我们。迁移规划应该从 Shopify 网站开发的第一天就开始,而不是等新商店已经建好之后才作为事后补充来考虑。
精选案例

电商 · 零售 · 迪拜
迪拜花艺精品店,基于 WooCommerce,围绕礼品市场打造快速结账流程。
thegorgeousflower.com
电商 · 时尚 · 迪拜
自 1990 年起经营的迪拜奢华长袍品牌,将其工艺延伸到快捷的移动端结账体验。
hanayen.com
电商 · 时尚 · 阿联酋
一个可持续服装品牌,顾客通过手机购物,期待店铺体验精致用心。
egosustainable.com博客文章
直接解答
没有哪一个总是更好。Shopify 适合想要一个托管平台、不想操心服务器管理,又希望用丰富的应用目录覆盖常见功能的卖家。WooCommerce 适合已经在用 WordPress、希望对结账流程和数据拥有完全掌控权,或者产品逻辑复杂到应用无法干净覆盖的企业。我们会根据你的产品目录、团队和系统集成情况来推荐,而不是给出一个千篇一律的答案。
可以。货到付款会被设置成一种人工支付方式,而不是通过银行卡网关,如果商店要提供这项服务,迪拜 Shopify 网站开发同样会涵盖这些订单如何与快递员实际收取的款项进行对账,因为货到付款的问题往往就出在这个环节上。
可以,不过这需要认真的模板级工作,而不是打开一个开关就行。Shopify 的主题结构会把已翻译的文字存放在语言文件里,但从右到左的布局、镜像的导航和阿拉伯语排版,都是我们要在模板层面内置进去的决定,不是 Shopify 会自动切换开启的功能。
可以,在平台支持的范围内,产品、客户、订单历史和内容都可以迁移过去,而且每一个现有的产品和分类网址都会被重定向到新的 Shopify 地址,这样搜索排名和已保存的链接就不会丢失。
你的产品、客户数据、订单历史和域名都归你所有,并且可以导出。店面主题和应用配置是建立在 Shopify 平台之上的,所以日后如果要离开,意味着要在别处重新搭建店面,不过你底层的业务数据依然会跟着你一起转移。
每个项目都会根据你的需求简报,在工作时间内45分钟内收到一份固定的书面报价,不附带任何义务。主要的计价因素是产品目录规模、是做定制主题还是基于现有主题、应用和系统集成的数量,以及阿拉伯语是否从上线之初就包含在内。
资料来源
书面固定价格
已收到,我们正在为您撰写报价。
工作时间内您将在 45 分钟内收到。请查收确认邮件。