当您将网页抓取作为服务销售时，您实际交付给客户的是什么？

简而言之：这周我开了两个关于我的自动化房产搜索工具的会议。第一个潜在客户已经有成熟的工具（一个潜在客户平台 + CRM），不过这里有人指出，可能还有20%的手动工作是这些平台没有覆盖的。第二个潜在客户有他自己的手动策略：他专门寻找那些只显示街道名称（没有门牌号）的房源——因为要将其转化为确切的建筑 + 楼层需要几天的手动工作（将广告照片与Google Street View逐个单元进行比较），而这正是他想要自动化的繁琐任务。我提供了那些已经在门户网站页面上直接显示门牌号的房源的街道+门牌号，以及可用时的楼层信息——但楼层数据有准确性问题，他自己通过比较保存的照片发现了一个错误。他真正想要的东西需要Captei已经商业销售的相同基础设施（通过公共API将市政/IPTU记录与业主姓名和电话进行交叉引用）——这与我拥有的完全不同。问题：这里的其他人实际上如何将抓取的房地产数据交付给客户？最终交付的是什么？跟进我之前关于从OLX抓取转向检测“分散”房源（同一房产由2家以上代理做广告=业主没有独家代理权）的帖子。此后，我开了两个实际会议，它们澄清了一些重要的事情。会议1（之前提到过）：潜在客户已经一起运行两个成熟的平台用于搜索 + CRM。不过，这里评论中的某人提出了一个好观点——那些“什么都能做”的平台通常是80%很好，20%笨拙，而这20%正是独立开发者仍然可以获胜的地方。我还没有测试这个角度。会议2（这周）：运行代理的人有他自己的手动流程，这恰恰澄清了真正的痛点在哪里。他专门针对那些只显示街道名称，没有门牌号的房源——对他来说，这些就是金矿，正是因为找到确切的建筑意味着几天的手动工作：将广告的室内照片与Google Street View逐个建筑、逐层比较，直到找到匹配。那种视觉匹配的苦差事正是他想要我的系统自动化的。我实际交付的：一个包含那些代理已经在门户网站上直接放置门牌号的房源的街道 + 门牌号的电子表格（结果证明有些代理只是懒得隐藏它），以及门户网站公开的楼层数据。出现了两个问题：楼层数据有错误——他比较了一个保存的房源照片与他对建筑的了解，说楼层不匹配。他真正想要的——将没有门牌号的街道转化为确认的准确地址 + 楼层——从根本上与商业工具（一个我们没有公共API访问权限的房产数据平台）已经在销售的东西相同：通过数据经纪人API将市政税收记录与业主姓名/电话进行交叉引用。这是一个不同于抓取器 + 电子表格的、更重型的构建。所以，给这个子论坛的问题：对于那些实际上已经将房地产潜在客户/数据抓取作为服务销售的人——你们最终交付什么？原始结构化列表、仅验证的地址、还是完全其他的东西？你们在哪里划定“足够好以收费”的界限？